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[57] ABSTRACT 

A system which uses three way password authentication, 
and s^DES to encrypt different portions of a logon packet 
with different keys based on the nature of the communica- 
tions link. Nodes attached to a particular LAN can have one 
level of security for data transfer within the LAN while data 
transfers between LANs on a private network can have a 
second level of security and LANs connected via public 
networks can have a third level of seooity. The level of 
security can optionally be selected by the user. Data transfers 
betwera nodes of a netwoik are icqyt in separate queues to 
reduce queue search times and enhance peifoimance. Each 
session maintains its own key dependent s%ES S-boxes to 
enhance security. 
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NETWORK WITH SECURE authentication, encrypting different portions of a logon 

COMMUNICATIONS SESSIONS packet with different keys based on the nature of the 

CROSS-REFERENCE TO RELATED communicatioDS link. Nodes attoched to a Pficul^.L^ 

APPT irxnnw^ ^^^^ secunty for data transfer within the 

AWLiUAiiuiN^ ^ ^j^^ transfers between LANs on a inivate 

This application is related to and is a CLP. of tiie network can have a second level of security and LANs 

commonly owned copending application entitled Network connected via public networks can have a third level of 

with Secure Communications Sessions, filed Oct 24, 1995, security. The level of security can optionally be sdected by 

bearing U.S. Ser. No. 08/547,346 and naming Minhtam C. the user. Data transfers between nodes of a network are kept 

Nguyen, the named inventor herein, as sole inventor, the xo in separate queues to reduce queue search times and enhance 

contents of which is specifically incoiporated by leferenoe performance. Eadi communication session is assigned a key 

herein in its entirety. dq)endent S-boxes table for a high level of security. 

BACKGROUND OF THE INVEmiON DESCRIPnON OF THE DRAWINGS 

1. Tedinical Field 

The present invention relates to computer network secu- HG. 1 is a diagram showing the connection between 

rity, In particular, it relates to networks whidi use dynamic aj^lications and the requester in a local system, 

packet headers and multiple levels of packet encryption to FIG. 2 is the diagram of FIG. 1 with a more detailed view 

transfer data to and from a remote server or to and from of the requester. 

another node in the local networiL 20 FIGS. 3A-B are a flow diagram illustrating data transfer 

2. Background Art between the ^plication and requester of the preferred 
The development of small independent systems sudi as embodiment. 

personal computers has provided several benefits to users. FIGS. 4A-C are diagrams of the memory layout of packet 

By providing each user with tteir own processor and data headers used in the preferred embodiment, 

storage, persons computers provide co^^^ 25 hGS. 5A-B are diagrams showing the memory layout of 

and data seomty. A cost of these benefits is the mconve- ^^^^ ^ ^ ^ 

mence which results firom the inabihty to easily access data ^^p/IP and NeffllOS. HG. SB is ttie memory 

by other members of an wganization. j ^^^^ ^ j^232 communications systems. 

Theuseofmainframesystems a^^^^ FIG 6 is a diagram of a multi-requester system with a 

of alternative systems such as LANs (Local Area Networks) 30 ^ ^ %M»6iait* « ^jo*;^ a 

and servers reduces the inccHivenience of mairinp data ^ 

available to aU membcxs of an organization, but results in FIG. 7 is a diagram iUustniting a single requester attached 

unpredictable perfonnance, and more importantly results in ^ servers. 

exposure of sensitive data to unauthorized parties. The FIG. 8 is a diagram showing a requester (machine A) 
transmission of data is conunonly done via packet based 35 interconnected with two servers (machines B-C). 
systems which have us^ ID and password information in a FIG. 9 is a diagram illustrating multiple requesters con- 
header section. Interception of a packet with header infca:- nected to servers via local area networks (LANs) and wide 
mation allows the intercepter to learn the user ID and area networks and public telephone ndwoiks. 
password which wiU in turn allow future penetration of the pjQ 10 is a diagram illustrating multiple requesters 
user's system and unautiiorized access to tiie user's data. It 40 connected to servers and server/requester systems, 
would be desirable to transmit user identification and pass- . ^ as^^^ ♦u-. ^ a- 
word information in a mamier which would be inded^ier- ^Sef e^fiST ^"""^ "'"^ 
able to an unauthorized interceptor. prercrrea enujooimem. „ . . 

Data security is endangered not only by access by outside ^ diagram illustrating fliercaj^ and 

parties such as hackers, industrial spies, etc, but also to 45 Packet queues used by the server of FIG. U. 

inadvertent disclosure of data to unauthorized members of FIG. 13A-D are diagrams illustrating the packet headers 

the OTganization. For exanq)le, data exchange at certain used in die logon procedure of die preferred embodiment 

levels of management may cause problems should die FIG. 13E is a diagram illustrating the packet headers used 

information be disclosed to the general ei]^}loyee popula- during data transfer in the preferred embodunent 

tion. Likewise, the transmission of personal infcoiation so fiiGS, 14A-C are diagrams of an alternative prefened 

sudi as banking codes over networks has exposed individu- embodiment of the memory layout of the pacfcet structures, 

ds using online finamdal systems to die possibility of ^^^^ ^ ^ iUustrating the logon packet 

firaudulent access to their funds by third parties. structures used in the logon procedure of die alternative 

In addition to data security, die use of network systems preferred embodiment 
such as LANshas a^d performance i^^^ 55 

queuing of requests from multiple locahons and die unpre- „sed during data tiSr in the altcniativepiSeiredembodi 

dictable delays associated witii queuing fluctuations. It u!w»winn8oawwww*«=ri""»cmua«auv 

would be advantageous if a system could p-ovide not only ' 

data security, but also more consistent performance. DESCRIPTION OF THE PREFERRED 

The prior art has failed to provide network systems which ^ EMBODIMENT 
ensure that access to data is restricted to authorized parties 

while at the same time providing more consistent perfor- to ^ detailed descnpUon of die figures, a general 

jntm cvL discussion of the operation of the preferred embodiment 

follows. A netwwk can take a variety of forms. For example, 

SUMMARY OF THE INVENTION jjg personal computers communicating via 

The present invention solves the foregoing problems by modem; it can be a single LAN system within a particular 

providing a system which uses three way password facility; it can be a remote server or mainframe system with 
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coimnunicatioiis links to individual tcmiinals or personal 
computers; it can be a network of LANs or other servers 
each communicating with one another or through one 
another; or it can be any of the foregoing systems wMch use 
not only dedicated communications lines, but also non- 
dedicated communications (Le. public networks such as the 
Ihtmet) through a "firewall**. The use of the teem firewall 
h^ein refers to the requirement ffx increased levels of 
security to avoid the possibility of unauthorized data access 
by parties outside of the organization. likewise, a machine 
in &e network can act as a client or a server depending on 
the nature of the data transfer. 

In the preferred embodiment, communication between a 
client and a servo* is as follows. The server waits for 
connection requests from clients on the network. The server 
can be started with one or more supported protocols to 
enable support of a variety of client types on the network. 
For example, the server protocols can include, among 
others, NetBIOS. TCP/IR modem and RS-232. All of the 
foregoing protocols are well known in the art. 

When a user on a client madiine wishes to initiate a data 
transfer or other function, the client application activates a 
requester to access resources in the network. When the 
server receives a request from a client application, it acti- 
vates a thread to process the request. A thread is an execution 
unit of an operating system. Operating systems used for this 
type of system are Microsoft Windows 95 (trademark of 
Microsoft Corporation), Microsoft Windows NT (trademark 
of Microsoft Corporation), IBM OS/2 (trademark of IBM 
Corporation). These systems may use multiple session pro- 
tocols such as NetBIOS and TCP/IP or single session 
protocols such as modem or RS-232. 

In single session protocols such as modem and RS-232, 
the same thread is used to process Uie request from a client 
since a serial port can act a server or client, but cannot 
simultaneously act as a server or client. Multiple session 
protocols create a new thread, referred to as an original 
thread, and wait for a request from a client When a request 
is received, the thread is referred to as a server processing 
thread which is used to process the client logon. 

After the logon is successfully completed, the server 
processing thread aeates a packet queue and a packet thread 
to receive incoming packets and place them in the packet 
queue. The server then waits for packets to arrive. On the 
client side, the client creates a session write thread to initiate 
contact with the server. In addition, the client creates a 
second thread which is referred to as the session read thread. 
This thread is used to receive packets sent from the server to 
the client. 

To use resources on the network, users must first logon the 
sender toprove their identity. Alogon request is sent from the 
client's logon application to the requester on the client 
conq)uter. Before logon data can be exchanged between the 
applications and the requester, a command manager is 
aeated by the requester to accept application requests. The 
command manager is responsible for housekeeping requests 
within the client computer. 

In the preferred embodiment the logon procedure uses a 
three way authentication to prevent the password from being 
transferred over the computer and also to allow both the 
client and the server to authenticate each other In addition, 
the authentication procedure prevents unauthorized penetra- 
tion of the system security by detecting the replaying of 
packets by third parties. 

The three way authentication system encrypts the very 
first logon packet with different keys for each part of the 
packet as follows. 
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The first stq> takes place at the client computer as follows. 
1- The client generates a 32 bit random number value whidi 
is concatenated to a predefined 32 bit constant to form a 
64 bit value R. 

5 2-TheCRCsignan]ieClofthe64bitvalueRandtheuser 
ID is calculated. This signature vahie allows detection of 
packet manipulation. 
3* The 64 bit Yalue R is used as a DES key to encrypt tiie 
user ID. This makes the user ID look random for each 
logon packet 

4- The client generates a 192 bit key K from the server name 
to encrypt the 64 bit value R. 

5- The client generates a key Ka from the user ID and 
password using a one way hash function such as the 
Secure Hash Standard (SHS) specified in the Federal 

IS Infonnadon Processing Standards Publication 180 (FIPS 
PUB 180). 

6- The client generates a random number Ra, calculates its 
CRC signature C2, and encrypts them with the signature 
CI using the key K2l This signature is used to validate die 

20 key Ka by the server. 

The second step in the process takes place at die server. 
When the server receives the first logon packet it decrypts 
the packet as follows. 

1- The server generates a key K2 from its machine name and 
25 the SHS to decrypt the packet header for identification. If 

the packet header does not contain the predefined 
constant, the user is unautiiorized. This occurs when an 
unauthorized user tries to access the server over the phone 
line but does not know the server name (since the phone 
30 number is a public record but the server name is private). 

2- If the user is authorized, the server uses the decrypted 64 
bit value R in the packet header as a key to decrypt the 
user ID. 

3- The server then uses the user ID to search a database for 
35 an access record. If the access record cannot be found, the 

user has entered an invalid ID and the session is termi- 
nated. If die access record is found, the server verifies if 
the user is allowed access to network resources at this date 
and time. 

40 4- If access date and time are verified, the server retrieves an 
associated one way hashed password Kb from an 
encrypted password file to decrypt the random number Ra 
and the CRC signatures. The password file is encrypted 
with a key Kk which is selected by the system adminis- 

45 trator at installation. 

S- The random numbers Ra and the CRC signatures are then 
decrypted. The server calculates the CRC signature of the 
padost header, the user ID and the random number Ra. If 
die calculated signatures matdi the decrypted signatures 

so CI and C2 stored in die packet, and if password Ka 
matches Kb« the server manipulates the dient random 
number Ra with a fs-edefined formula, generates a random 
number Rb, and encrypts both random numbers Ra and 
Rb with the password Kb before sending the first logon 

55 response packet to the client 

The tiiird step in the process takes place at the client 
computer as follows, 

1- The client decrypts the first logon response packet 

2- The client manipulates the random number Ra with the 
60 predefined formula and compares it with the one returned 

from the servo:. If the numbors match, the client knows 
that it is connected to the correct servo*, not a fraud server 
from which an eavesdropper has captured transmissions 
from the previous logon and is echoing packets back to 
65 the client computer. 

3- The client manipulates random number Rb witii another 
predefined formula and concatenates it with the client's 
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initiatiog data (i.e., the client initial packet sequence ha( )=a hash fanction to mantpulat g i^ndmn numtier 

number, the encryption and compression mode for the Ra 

session, and the operating system platfonn ID) to form a Rb^a 64 bit random value generated by S 

second logon packet The operating system platfonn E) is hb( >=a hash function to manipulate the random number 

useful for selecting protocols and data formats when as Rb 

particular client or server is communicating with systems Dc=client initial data 

that may have any one of a variety of operating system IV=an initial chaining vector for encryption 

software programs running. The client would typically session encryption k^ 

request encryption and compression mode for the session. Ds^erver initial data 

However, the server may indicate that the particular lo R'a=ha(Ra) 

modes requested are not available. R'b=fab(Rb) 

4- The client then encrypts the second logon packet and ^^8°° p-ocedure may be listed as: 

sends it to the server. 1. C to S: EK(R>4^Ka(Ra,fO[ia,g(R,UID) )+ER(UID) 

The fourth step in the process takes place at the server 2. S to C: EKb(R'a,Rb) 

computer as follows. 15 3. C to S: EKa(R'b,I>c) 

1- Tlie server decrypts the second logon pactet 4. S to C: EKb(IV,Ks,Ds) 

2r The server manipulates the random number Rb with the An important, advantage of the authentication procedure 

same predefined fonnula used by the dient and verifies if used by the preferred embodnnent is that both the client and 

the random numbers are matched. If the random numbers the server verify each other as legitimate without sending the 

match, then the server knows it is communicating with an 20 password. In addition, the use of a second set of logon 

authorized client and that the first logon packet was not a packets which contain different encrypted random numbers 

replayed packet precludes access by an unauthorized intruder who merely 

3- The server saves the client initiating data, generates a replays intercepted packets. 

session key Ks and an initialization vector IV. In the Theheartof this authentication procedure is in the middle 

preferred embodiment, Ks and IV are generated using a 25 part of the logon packet, which contains the random nuniber 

formula similar but more secure than the one specified in Ra and the CRC signattires. Since fee CRC signature of the 

Appendix C of the ANSI X9.17 standard. random number Ra is encrypted and sent along with the 

4- Ks and IV are sent to the client along with the server logon packet, the server can authenticate the user right on 
initiating data (Le., the server initial packet sequence the first logon packet. The manipulation of the random 
number, supported and/or approved encryption and com- 30 numbers Ra and Rb in the challenge-response fashion is to 
pression modes for the session, and the server operating help the server defeat the replying of the logon packet and 
system platform ID). to allow the client to authenticate the server and to defeat 
The client and server initial packet sequence nmnbers are packet replaying as weE 

used to detect packet deletion and insertion for data The 32-bit random number in the packet header is used to 

exchanged after the logon procedure. 35 make fee packet header and fee user ID look different for 

The fifth step in fee process takes place at fee client every logon padcet The one-way hashed server name Is 

computer as follows. used as a key to quickly detect invalid logon packets before 

1- The second logon response packet is decrypted by fee seardiing fee database. This case may occur fircquently 
client when fee modem protocol is activated to wait for data 

2- The dient encrypts Ks and IV wife its own key and saves 40 transferred over a telephone line (Le., a wrong number is 
feem in mcmoiy for future communication wife fee dialed by accident or a call generated by a manual or 
server. The logon procedure completes here. automated telemarketing con^any is being received). 
After fee logon procedure is successfully completed, all In addition, fee server name is isolated fi-om fee user ID 

packet headers are encrypted using fee session key Ks and and password when creating a one-way hashed password to 

fee IV. Hie packet headers arc encrypted to prevent intruders 45 allow fee portability of fee database. For example, when a 

from deleting, Inserting, modifying, and/or replaying fee business grows, anofeer server may be needed at anofeer 

packets which may have been captured while data was location and fee database can be easily transferred to fee new 

exchanged over communication lines. server. Of course, it would be less time-consuming to delete 

For ease of illustration, fee following symbols can be used unaufeorized users from fee database than to add aufeorized 

to illustrate fee logon process: 50 users to fee new one. To better protect fee valuable infOT- 

Where: mation in fee database, a password is required before access 

C=a client to fee database is granted. More important fee database can 

S=a server be shared among servers. For exanqde, a server Sb can 

Esa symmetric cryptosystem such as DBS receive fee first logon packet and forward fee user ID to a 

Ksan encryption key generated from fee server name ss database server Sc within a private network for verificatioa 

32 bit random number concatenated wife a pre- If an access record is found and fee user can access fee 

defined constant server Sb at this date and time, fee database server Sc returns 

Ka=a 192 bit toy one way bashed from the user ID and fee encrypted one-way hashed password Kb to fee server Sb. 

password The server Sb feen continues fee challenge-response as if fee 
Ra=a 64 bit random value generated by C 60 password Kb is returned from a local database. Note that fee 
f( )=a hash function such as CRC to calculate fee database server Sc can encrypt fee one-way hashed pass- 
signature word Kb wife fee session key defined for communication 
g( )=a hash function sudi as CRC to calculate fee between fee server Sb and Sc before sending it across fee 

signattu-cs private network is security is desired. 

UII>=user IDs 65 In comparison to prior art systems, fee design of this 

Kb=a 192 bit one way hashed key retrieved from a invention provides fee server a better opportunity to resyn- 

database chronize itself if fee first logon packet is invalid since fee 
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receiver of the authenticating packet is in control of what is router releases the write token for use by another thread in 

next, not ttie sender. On the other hand, in the prior art the the same process or a different process, the packet was 

sender is in control of what is next For example, the sender sent to the server successfully, the request router 106 waits 

generates a public key, encrypts it with a shared secret key for the corresponding response packets, i.e., a packet can 

and sends it to the receiver. If the secret key is invalid, the s cause multiple response packets returned ficom die server, 
receiver cannot detect it Thus, a certain number of packets When a response packet airives, the session read thread 

must be received before the receiver can resynchronize or uses the response signal to tell the corresponding request 

the receiver might have to use a timeout to resynchronize router that its response packet has come and is available in 

itself. the read token. At that time, the read token is accessed 

Finally, the logon protocol of the preferred embodiment is lO exclusively by the designated request router. The router then 

more suitable for a client/server distributed environment, transfers data in the response packet directly to the appli- 

because this logon protocol allows both client and server to cation's buffers and signals the session read thread 202 of 

authenticate each other without sending the user password the communication channel 114 that the read token 206 is no 

across die communication media and prevent intruders from longer in use so that the session read thread 202 can re-use 

deleting, inserting, modifying, or replaying the logon pack- 15 the read token 206 for other incoming packets. Finally, after 

ets. In addition, if the logon procedure fails at any point, the all response packets of a request packet have arrived, the 

server releases all resources and destroys the connection request router 106 destroys the response signal and returns 

without sending the response packet at that point, Le., if the control to the application 102. The final response packet is 

user enters a wrong server name in the very first logon determined by a bit in the packet attribute, 
packet, nothing is sent out from the server to prevent the 20 The request router 106 sends a message to the command 

user, a potential intruder, from knowing anything about the manager of the requester 110 to request the conmiunication 

server. Note that this mutual authentication technique handle containing information of the read 204 and write 208 

requires the client noachine to have a local CPU so that the tokens and thdr associated resources. If the handle already 

password will not be transmitted over the network before exists, it is passed to the request router 106 immediately 

being encrypted. 2S after the requester 110 increments the access count of the 

The cUent can now peif onn a mounting procedure to link handle. However, if the handle does not exist at that time, the 

a network resource on the server to a virtual disk or it can requester 110 will load the appropriate communication 

identify a network resource with the following format library, allocate the tokens 204, 208 and their associated 

\\servername\netname. The communication protocol resources, create a communication channel consisting of a 

selected at logon is used for communication between a 30 session write diread 206 to perform auto-logon, create a 

particular client and the server. This method allows com- session read thread 204 for the communication channel 114 

munication between a client and network domains, between if auto-logon is successful, and inaement the access count 

a network domain and other network domains using multiple of the handle before passing it to the request router 106. 
communication protocols. Therefore multiple clients can After receiving the handle, the request router 106 saves 

communicate with a single server, each client using a 3S the handle for use during the entire lifetime of the applica- 

different protocol if desired. Also a single client can com- tion. When the application 102 terminates, the request router 

municate with multiple servers, also using different proto- 106 will signal the requester 110 of the event so that it can 

cols for each server. deaement the access count of the handle. When the access 

Referring to FIGS. 1 and 2, these figures illustrate the count is zero for a certain period of time, the session 

interconnection between a client and a sender. FIG. 2 is a 40 manager of the requester 110 will drop the communication 

more detailed view of the system of FIG. 1. session, release the tokens 204, 208 and their associated 

To perform a file transfer operation, an application 102 resources, and unload the communication library. Thus, this 

calls a request router 106. The request router first verifies if method allows resources to be allocated upon demand and 

the application 102 requests a local or remote resource. This released when no longo* in use. Furthermore, the request 

verification is performed using a local mounting table 104 4S router 106 can translate and format data in fiie application 

which the request router 106 obtains from the requester 110 timeslices while die requester 110 is communicating with 

when the application 102 is first started. comnmnication devices 120, 122, 124, 126 to better use die 

If the resource is local, the request router 106 calls a local CPU time, 
system fimction call to perform the request and returns the The request router 106 can also perform any pr^>aration 

control to the application 102. However, if the resource is 50 necessary to transfer the ai^lication 102 request to the 

remote, the request router 106 first searches its local list to requester 110 before requesting the ownership of the write 

see if the needed communication handle is already stored in token 208 to reduce the time it takes to access the write token 

the list. This conmiunication handle contains information of 208. In addition, the request router 106 remembers resources 

the read 204 and write 208 tokens (shown in FIG. 2) and for one application 102 at a time. Thus, it reduces the time 

their associated resources. If the communication handle is 55 to search for the needed information. With this method of 

not found in the local list, the request router 106 sends a sending and receiving packets, data can be exchanged asyn- 

message to the requester 110 over the request channel 112 to chronously between a client and a server with minimum 

obtain the handle. Once the handle is obtained, the request resources in a minimum time. In addition, request packets 

router 106 aeates a response signal, i.e., a return address, can be accumulated on the server for processing while the 

requests the ownership of the write token 208, stores the 60 previous response packet is processed by the coimnunication 

response signal into the packet header, builds a packet based devices 120, 122, 124, 126 or traveling over the network, 
on the application's 102 request into die write token 208, Message channel 128 and message manager 130 are used 

and signals the session write thread 206 of the communica-. to control system messages transmitted in the system. Cur- 

tion channel 114 diat there is a packet to send. rent mounting table 134 and global mounting table 132 are 

If the application data is larger than the packet cqiacity. 65 used to identify usage of system resources. The session 

die request router 106 can send multiple packets in a soies control manager is used to control each session between a 

at diis point After the packet is sent to die server, the request client and a server. 
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In order for the Requester 110 to perfoim a secure 
automatic logon after the Session Control Manager 136 has 
drq>ped a session due to being idle, the Requester 110 must 
save user ID and password in the Global Mounting Table 
132. However, not the original password is stored in the 
table; but the one-way-hashed key Ka generated from the 
user ID and passw<»:d is saved. This key Ka is encrypted 
with another key generated randomly every time the 
Requester 110 is started to further protect it The original 
password is erased from memoiy immediately after it is used 
to generate the key Ka. 

When an application need to communication with the 
remote server, the request router 106 will download ttie 
Current Mounting Table 134 into the Local Mounting Tbble 
104 in the application's process space by sending a down- 
load request to the Command Manager 140 of the Requester 
110. The name of the remote server can now be retrieved 
from the Local Mounting Table 104 by the Request Router 
106. This remote server name is used to request a commu- 
nication handle from the Requester 110. 

When the Requester 110 performs automatic logon due to 
a request from a Request Router 106 for a communication 
hancUe, the Command Manager 140 searches the Global 
Mounting Table 132 to find an appropriate server name. If 
the server name cannot be found, the user has not performed 
logon manually. However, if the server name is found, the 
Command Manager 140 will create a Session Write Thread 
206 and its associated resources, decrypt the encrypted key 
Ka and store logon information sudi as the user ID, the key 
Ka, and the server name into the Session Info Block as 
shown in FIG. 5A-B. The auto-logon procedure is then 
perf oimed by the Session Write Thread 206. After the logon 
procedure is successfully completed, die Session Write 
Thread 206 will automatically create the Session Read 
Thread 204 as described earlier. A return code is then 
returned to the Command Manager 140 of the Requesta to 
indicate success or failure. If the auto-logon is successfril, 
die Requester 110 returns the communication handle to the 
Request Router 106. Otherwise, an error code is returned to 
the Request Router 106. Compression engines (CE) 138 are 
used to compress data for performance reasons. 

If the user has selected compression for the communica- 
tion session, a compression work buffer will be allocated by 
both the client and server during the logon procedure. 
Therefore, tninimu m resources are allocated for better 
performance, because the compression work buffer is only 
allocated when it will be used. 

FIG. 3A and B is a flowchart which illustrates the transfer 
of information in a session after the logon procedure has 
con^)leted. When a resource request 302 is made, the system 
304 first tests to see if it is for a local resource 304. If so, a 
local function is called 312 and control is returned 310 to die 
application, it is not a local resource, die system creates a 
response signal 306. If the response signal 306 cannot be 
aeated, control is returned to the application. If it is, then the 
local list is searched 314 fcH^ the communication handle. If 
the communication handle is not found 316, a communica- 
tion handle is obtained 318 from the requester and then 
ownership if the write token is requested 320. However, if 
die communication handle is found 316, then ownership if 
die write token is immediately requested 320. 

If no error occurs when the request f(x ownership of the 
write token is made 322, then the response signal is stored 
in the packet header 326, a request packet is built into the 
write token 328, the write thread sends the packet, and the 
write token is released 332. If an error is detected when the 
packet is sent, die response signal is destroyed 342 and 



8,448 

10 

control is returned 344 to the application. If no enrors occur 
during packet transmission 344, then the system waits 336 
for die response packet, die data in the response packet is 
transfened 338 into the application's buffer, the read token 

5 is released 340, the response signal is destroyed 342 and 
control is returned 344 to die application. 

FIGS, 4A-C illustrate die memory layout of die packets 
used in the preferred embodiment FIG. 4A illustrates a 
packet as encrypted by security level 1. In security level 1, 
the packet header is encrypted using single s^ES encoding. 
This level of security incurs the least amount of overhead 
and is preferably us^ in more secure environments such as 
LANs. However, if the remote client or server is outside die 
U.S., dien die standard DES is used widi a 40 bit key to 
weaken security to con^)ly widi U.S. law. 

^5 FIG. 4B illustrates a packet as encrypted by security level 

2. In security level 2, the packet header and data are 
encrypted using single s^ES encoding. This level of secu- 
rity incurs slightiy increased overhead as conq}ared to 
security level 1, but provides an increased level of security 

20 for less secure environments such as wide area networks. 
FIG. 4C illustrates a packet as encrypted by security level 

3. In security level 3, die packet header and the data are 
encrypted using triple s^DES encoding. This level of secu- 
rity incurs die most bverhead as compared to securify levels 

25 1 and 2, but provides the highest level of security for 
insecure environments such as public telephone networks or 
the Internet 

To protect data exchanged over communication sessions, 
the preferred embodiment provides two different encryption 
schemes available to the user at logon. The first scheme is 
the single s^DES and the second scheme is the triple s^DES 
similar to die one specified in die ANSI X9. 17 and ISO 8732 
standards but with 192-bit keys. In addition, die preferred 
embodiment applies the standard Qpher Block Chaining 
mode specified in die FIPS PUB 8 1 to better protect the data. 
Once an encryption sdieme is selected, data exchanged over 
all sessions connected to a network domain are encrypted 
regardless of the communication protocols being used by the 
sessions. The price to paid for die encryption is minimum 
anyway since the preferred embodiment encrypts 500,000 

40 bytes per second when running on a Pentium 66MHz 
processor. The operating system used can be any suitable 
personal computer operating system such a Microsoft (TM) 
Windows 95 (TM), IBM (TM) OS/2 Warp (TM), Unix, etc. 
If the server is a large system, any one of a number of 

45 suitable mainframe operating system software may be used. 
In addition to die above encryption schemes, die preferred 
embodiment employs a dynamic packet header technique to 
provide extra securities based on the security level selected 
by the user at logon. If a security level 2 is selected, the 

30 packet header and data are encrypted widi s^ES and die 
packet header is changed to 24 bytes to cany die CRC 
signatures of the packet header and data for authentication. 
However, if a security level 3 is selected, the packet header 
and data are encrypted with s%ES using three different 

55 keys. Finally, if securi^ level lis selected, the packet header 
remains at 16 bytes and no signature is verified for a better 
perf (amance but the packet header is encrypted widi s^DES 
to provide security against other direads. Thus, thanks to the 
dynamic packet header technique, a user can setup different 

fiO types of firewalls wherever he needs them. For instance, the 
user can connect to his office from his home using security 
level 2 and setup his office machine to connect to anc^er 
server within his organization using a lower security level to 
gain a better performance. However, if performance is 

65 critical and the network is relatively secure, security level 1 
can be dianged sudi that no encryption occors for the packet 
header: 
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In Older to provide better seouity, the prefeired embodi- any subdirectory at all when viewing the network resource, 

ment allows the user to select if the data should stay in its If for some reasons the user knows a particular subdirectory 

enaypted form so that only authorized personnel can view exists under the network resource, he cannot access it 

the data. This is important for sensitive business data, anyway. The management of network resources and user 

personnel data, etc. Of course, the key to decrypt the data 5 access permissions is provided with a user-friendly Graphi- 

must be agreed to ahead of time or exchanged over some ^al User Interface application. Together with the logon 

secured diannds to protect the secrecy of the k^. procedure. ACLs provide effective protections to the 

Of course, those skiUed in the art will recogmze that the rtsoutccs on the network domains, 

user could also have the capabiUty of instructing the system pj^ j2 is a more detailed view of the server 1004 of HG. 

that no encryption wiU be used ]to ^ ^^^^^^ ^ 1^22 within the server 1004 is 

wou^d represent a fourth f^j^ ^^^f ^ responsible for communication between the server 1004 and 

Secunty level M having been discussed in regard to HG. appUcations on the server 1004 machine. Hius, the 

' HGS. 5A-B iUustrate the packet queue structure used in server 1004 can be informed if a database has b^n changed 

the preferred embodiment HG. 5A iUustrates the TCP/IP ^ resource control apphcation. The server 1004 can also 

and NetBIOS communications structure and FIG. SB iUus- accept a message from another appUcation 102 to send to all 

trates the modem and RS-232 communications structure. <^ selected cHents over active sessions. If an electronic mail 

Hie con^ressed buffer is a work buffer used to compress system should be needed, the server 1004 can save the 

data prior to transmission. A packet header is placed at the message and wait until a client is logged on to send the 

beginning of the read token and at the beginning of the write message over the session. To support these features, the 

token. In the preferred embodiment Sit read and write 20 control manager 1122 posts message or e-mail packets to the 

tokens are stored in shared memory. incoming pacl^t queues 1206 of the sessions 1120. When 

FIG. 6 illustrates a configuration in which multiple the server processing threads 1114, 1116 of die sessions 1120 

requesters 110 comnounicate with a single server 602. retrieves the packets from the queue 1206, it wiU process the 

FIG. 7 illustrates a configuration in which a single packets based on the packet types defined in the pack^ 

requester 110 comnumicates with mult^le servers 602. 25 headers. 

FIG. 8 illustrates a configuration in which a system 802 jqQ *i3a-.d illustrates the packet headers used in the 

and multiple servers 864 rommunicate with one another. ^ procedure. A session key KS and an initialization 

FIG. 9 IUustrates a configuration m which multiple sys- ^^^^^ jy ^ communication session between 

terns 802 and multiple servers 804 comnmrncate with one ^ ^^^^^ ^ ^^^^ ^^^^ 1^^^ ^ ^ 

another via modems 124 over phone lines 906 and also over j • j /• 1 1 ^ i • j\ 

Ss 902 rd wMe^ernetS 904. This figure iUus- ^° ^ '^"""^ ^^^^^ encryption is used). 

JSTs ^e aSTof system to interface with multiple , ^^'if f ^"'^ '"'^ 

communications protocols. durmg data tmnsf^. When an e-mail or message packet is 

FIG. 10 illus^tes a configuration in whidi multiple ^^^^t, the preferred embodiment uses secunty level 2 by 

requester systems 1002, multiple server systems 1004, and dcfaxHt to protect the messages. In secunty level 2, both 

multiple server/requester systems 1006 communicate with 35 packet header and data are encrypted using single S3DES 

one another. The configuration in this figure is similar to that encryption. 

shown in FIG. 9. Th^ requester also has the capability to signal request 

FIGS. 11 and 12 illustrate a configuration in a server 1004 routers 106 of all applications 102 when a communication 

which includes communication sessions 1120 to communi- session is terminated abnormally whether the request routers 

cate with requesters, encrypter/decrypter 1128, read threads 40 106 are sending request packets or waiting on response 

1114, write threads 1116, packet queues 1110, 1112, a packets. In ord^toperform this feature, the response signals 

resource control manager 1102 to control user ID, access (i.e., the return addresses stored in the request packets) are 

permission and alias and path storage 1104, 1106, 1108. The saved in response-signal queues by the session write thread 

cached user ID and access permission 1124 and the cached ^ach communication session has a response-signal 

alias and associated path 1126 caches are used to store data 45 que„g 12O6 to reduce tiie search time. When the response 

from the access pennission storage 1106 and the alias and packets are successfully dcUvcred, their corresponding 

patii storage disks 1108 for improved system performance. response signals are removed from the queue by the session 

?^?'ff/AT''^' ''f^'f ^T"'- ^ read threads 1114 of the correspondLg communication 

control hst (ACL) IS usedfor each ne^^^ ^^^^^^ appUcation 102 termhiates before its 

penmssion storage 1106. The ACLs are managed by net- , 1 * • *u 1 « ^- .i^^ 

work administrators to define to which resourc^ a user can °f ^ P^^^^^^ ™' ^*^?P^°^^ packete are discarded 

access and what kind of accesses the user has to each the response signals are also removed from the queue 

resource. The system provides a sophisticated ACL so that ^ ^ <^^^°^"g ^^^P^^^^ P^^^^^^s have amved. 

a user cannot view or access any resources other than those ^ addition, the read thread of the chent session also 

assigned. The following access permissions are used by our recognizes different types of packets to determine whether it 

^QLs : 55 should route the received packets to the application 's request 

READ JILE router or to a message manager within the requester. The 

<^^j^jPQ PILE message manager ofthe requester is responsible for message 

prjP*rp^ PjjD and e-mail packets sent from the connected servers. This 

nPT FTP Fn p feature is important because it allows the server to initiate 

utJMitS^iLti ^ sending of packets while a session is active. As an 

EXECUTE_ J[LE example, a hot-link can be defined so that a server can 

CHANGE_ATTRIBUTE inform the connected clients if a database should be changed 

ACCESS_SUBDIR or a server administrator can send a message to all or 

CREATB-^UBDIR selected clienU telling them if a server should be out of 

REMOVE^UBDIR 65 service shortly, etc. In a more advanced ^plication, an 

For example, if the user is not permitted access to any electronic-mail server application can be written so that the 

subdirectories from a network resource, the user will not see message packets are saved on the server until a client is 
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logged on. At that time, the server will send the saved added or removed from the memorized list In addition, 
messages to die connected dient security audit can be tumed on and off by the ne^ork 

In (he prior art, the requester is the one that translates and resource manager running on tfie server over the control 
formats requests firom the applications; thus, it cannot per- channel of the server. The network resource manager can 
form preparation ahead of time. In addition, inf<Hination s toggle the security audit for users or groups whose IDs are 
accumulating in one place could increase the search time. supplied in the auditing request packet, or resources whose 
The prior art requires an intrinsics modules in both the names are stored in the auditing request packet The audit 
application and the requester which may require more can also be logged based on successful, failed, or both 
resources to be allocated and more machine instructions to transactions. 

be executed. Furthermore, the prior ait does not have the lo In the prior art, the application is the one which deter- 
capability to accumulate multiple request packets from a mines if a session should be started on the host compute; 
requester so that the server can {H-ocess the next packet The application then makes a function call to connect to the 
request while the previous response packet is traveling back host conq)uter and another function call to start a host server 
to the requester on the network or being processed by process. In die preferred embodiment, the command man- 
communication devices in their own memory buffers. is ager of the requester determines if a connection should be 
In contrast to die prior art, die preferred embodiment established to couple the client computer to the server 
contains the fnmatting and translating code in just one computer. Once die connection is established, the server 
place, the request router 106. Hie requester only compresses automatically creates a server processing ttu^ead to process 
and/or encrypts packet headers and packet data if necessary the client request packets received over die connection. After 
and then calls the transport functions to send the packets to 20 die connection is established, the command manager also 
the server. In addition, requester 110 is also responsible for performs the auto-logon itself, not the qiplication. The 
saving logon and mounting information, managing the com- session can dien be shared by all the applications on the 
munication sessions, and delivering response packets client madiine. 

received from multiple network domains to multiple request Thus, the session creation and automatic logon, re-logon 
routers while sending request packets to the multiple net- 25 or auto-logon are transparent to die ^plications. If the logon 
work domains. Requester HO does not need to know the is successful, die server aeates a server receiving thread to 
format of the response data, and can deliver the re^nse receive and accumulate request packets in a packet queue so 
packets immediately upon receiving them. The request rout- that diey will be processed by die server processing tfuead, 
ers 106 can then format or translate die response data in die When a session disconnect request packet is received, die 
applications time slices while the requester 110 is waiting 30 server receiving and processing threads terminate them- 
for other incoming response packets or reading data from the selves. However, if the communication session is destroyed 
communication devices 120, 122, 124, 126. Thus, the pre- abnormally, the server receiving tiiread simulates a discon- 
ferred embodiment achieves better performance dian the nect request packet and appends it to the packet queue to 
prior art signal the server processing diread to tenniDate. The server 

The prior ait also requires the intrinsic modules to tzans- 3S recdving thread then temiinates itself, 
late and format the i^lication data from a program stack Note that in the very first logon manually performed by 
segment to a parameter block befwe sending it to its die user, the operation is sUghtiy different than die auto- 
requester where the data is once again fonnatted or copied logon mentioned in the above paragr^h. The requester first 
into a data communication buffer: In contrast, die request receives a logon request from the logon plication, it 
routers 106 in die preferred embodiment fonnat the appU- 40 establishes the session itseff and then performs the logon, 
cation data only once and store the formatted data into the This is so done by die command manager of die requests, 
write token whidi will be used by the requester and die not by die session manager. The session manager is respon- 
communication subsystem to send die request packets to die sible for dropping the session ff no data is transmitted for a 
server. When the response packets arrive, the requester HO certain period of time. 

uses die response signals to tell the ccnresponding request 45 Since request padc^s are accumulated in die packet queue 
routers diat dieir response packets have arrived. At diat time, in die preferred embodiment, the request packets may not be 
the request routers 106 transfer response data directiy from processed immediately upon asrival. In contrast, die prior ait 
the read tokens into the application buffers. Thus, the must process the request packets immediately to retum the 
preferred embodiment eliminates the overhead of copying status or data to the requester. This may indicate diat other 
data between memory buffers. SO applications on die client computer must wait until the return 

Furthermore, the prior art does not have the dynamic packet has arrived and processed b&fan diey can send their 
packet header feature to support packet authentication on requests to the same host computer, 
demand. Neither does its server authenticate the requester to The prior art requires an application to send a function call 
prevent replaying of packets by intruders. The prior art also to the host computer to established a communication ses- 
requires two different programs running on the server to wait 55 sion. Our system establishes a communication session by the 
for inconoing data from different communication protocols. requester when it receives a logon request from die logon 
The prefened embodiment only requires the server to be program or a request router asking for the communication 
started once for multiple communicatioD protocols. handle. In addition, our server has die capability to reformat 

In general, a session on die server 1004 will support and retranslate die request packets in its own request router 
multiple applications on the requester; dius, a server 1004 60 before forwarding them to the requester located on the 
must somehow remember the resources allocated for the server when the network resources do not reside on the 
client applications so that these resources can be released server. That is, multiple servers can be connected togedier as 
whedier the client applications terminate abnormally or die shown in FIGS. 7-10 to e^and the amount of network 
communication sessions are destroyed abn(smally. Our resources available to requesters. Note that diis feature 
server supports diis feature in each session thread. Since the 6S requires the intermediate servers administrator(s) to manu- 
allocated resources are isolatedly remembered for different ally logon the designated servers since die logon passwords 
requesters, the seardi time is minimum every time they are are not stored on the intermediate servers. Users on request- 



08/09/2004, EAST Version: 1.4.1 



5,638,448 

15 16 

ers can peifonn this logon remotely if their access permis- and server to generate a for the S-boxes. Thus, security 

sions in the ACLs of the intermediate servers indicate that of data exchanged over the communication channel is not 

they can execute programs on the intermediate servers. only dependent to the session encryption key but also to the 

However, caution must be taken and security level 3 is S-box key. 

advised when using this feature since logon user IDs and 5 In FIG. 15A. the 64 bit R field in the beginning of the 

passwords must be sent along with the executing request header includes a 32 bit constant which identifies the source 

packets. system of the packet. The R field is used as a key to encrypt 

As shown earlier, the very first logon packet is encrypted the 16 byte field which holds the User ID. For use in 

with three different keys for different parts of the packet. The international communications, the high order 24 bits can be 

header of the logon packet is encrypted with a key generated lo set to zero. By so doing, the level of encryption security can 

from the server name. This is design to detect outside be reduced to comply with United States laws governing 

intruders early in the verification process. For intruders encrypted communications. 

working inside an organization, the server name may be The logon procedure facilitates a thrp^ -way fliit^iftntira-^ 

known. Then it comes the middle part of the logon packet ^on to prevent the password from bein^ f rflngfrrrft^i avw \\tp^ 

which contains the 64-bit random number and the CRC 15 network and allows both client and server to authenticate. 

value. Hiese are the heart of the verification since it is each other as well as-detecting packet replaying . First, the 

encrypted with the key generated from the user ID and the client generates a 32-bit random number V concatenated by 

scCTCt password. This scheme allows the server to detect the a predefined 32«bit constant toJonnTSPbit number It This 

intruding logon right on the very first packet. The challenge- 64-bit random R is used as a s^DES key to encrypt the iiser 

response process that following the l(^on packet is to defeat 20 ID to make the user ID look random for every logon packet 

re-played packets. iTien the client generates^a 64-bit key K from the servg 

The encryption system used in die preferred embodiment name to.encry pt the 64~bit value R. N ow, the client generates 

has several other advantages, as follows. The long term key a 192 bit key Ka from tfae,u&er ID_ and password using a_ 

is derived from a uso: ID and a secret password. It has 192 one-way hash function ■such^_t he Secu^ Hash Standard 

bits and is used in a s^DES encryption enhanced with Cipher 25 (SHS) sp ecifiedin the Federa l Trtf^rp^tiQ^ prprfigging gt^^n- 

Block Chaining (CBC) mode. The short term key is gener- daxds Publication 180 (FIPS PUB 180). It then generates a 

ated with a formula similar but more secure than the one 64-bit random number Ra, calculates t\ \^, CRC S^gn^t^^r^ ^ 

suggested in X9.17 and changed every time a session is whose initial value is ttie random number V and consisting 

established between two nodes on die network- Thus, the of the random number Ra, the original user ID, and the 

encryption occurs at the application layer which exposes the 30 random number R. The client then encrypts the random 

source and destination addresses of tiie packets when used number Ra and the signamre C using the key Ka. Thus, the 

with TCP/IP and NetBIOS protocols but the intruders must very first logon packet is encrypted with three different keys 

deal with different keys whose lengths are either 40, 112 or for different parts of the packet (see FIG. 13A-D). 

240 bits for different pair of nodes on the network. In When the server receives the first logon request packet, it 

addition, the short term key is encrypted and only sent once 35 generates a key K2 from its machine name and the SHS to 

when the communication session between two nodes is decrypt the packet header for verification. If the packet 

established, not in every packet; thus, it reduces the traffic header does not contain the predefined constant, the user has 

between two nodes. selected a wrong server, Le., the user tries to access the 

Furthermore, the prior art only protects date between server over the phone line but does not know the server 

site-firewalls, not between nodes. In many cases, data must 40 name since the phone number is a public record but the 

be protected between nodes within an organization. For sarver name is a private one. However, if the packet header 

instance, high-rank management of&cers within a private contains valid data, the server uses the decrypted 64-bit 

network may want to exchange restricted confidential infer- packet header as a key to decrypt the user ID. The user ID 

mation without leaks to their employees. is then used to search a database for an access record. If the 

Encryption at the application layer also reduces the cost of 45 access record cannot be found, the user has entered an 

replacing the existing network layer and can be done on invalid ID and the session is terminated. However, if the 

d^nand when protection to data is needed. Different security access record is found, the server verifies if the user is 

firewalls can easily be established between any pair of nodes allowed to access the network resources on this date and at 

with a single click <rf the fingertip. this time. 

FIGS. 14A-C and 15A-E illustrate an alternative pre- 50 After the access date and time are verified, the server will 

ferred embodiment of the invention. FIGS. 14A-C illustrate retrieve the associated one-way-hashed password Kb from 

the memory layout of the packets used in the alternative an encrypted password file to decrypt the random number Ra 

preferred embodiment. FIGS. 14A-C differ from the and the CRC signatures. The key Kk used to decrypt the 

memory layout shown in FIGS. 4A-C in that the "PKT password file is selected by the server administrator at 

VERSION FIELD" has been deleted. This reduces the 55 installation. The key must be entered every time the server 

amount of data to be transferred in the packets which in turn process is started since it is not stored on the system, 

reduces storage requirements and improves performance. Now, the first logon packet is decrypted. The server 

FIG. 15A-D illustrate the packet structures used in the logon calculates the CRC signature of the random number Ra, the 

procedure of the alternative preferred embodiment A ses- user ID, and the random number R. If the calculated signa- 

sion key KS and an initialization vector IV are defined for 60 tures match with the decrypted signatures C stored in the 

a communication session between a client and a server 1004 packet, the server manipulates the client random number Ra 

when security level 1 or higher is desired. with a predefined formula to form Ra*, generates a random 

FIG. 15E illustrates a normal packet structure such as that number Rb, and encrypts both random numbers Ra' and Rb 

used during data transfer, when a s^DES algorithm is in use. with the password Kb before sending the second logon 

tts S-boxes are cryptographicaUy modified and selected 65 packet to the client 

based on a given key. In the preferred embodiment die After the client decrypts the first logon response packet, 

random numbers Ra and Rb are XOR*ed to by both client it manipulates die random number Ra with the predefined 
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fonnula and compares it against the one returned from the 
server. If the numbers match, the dient knows that it 
communicates with a correct server, not a fraud server where 
an eavesdropper has set up to echo back captured packets. 
The client now manipulates the random number Rb with s 
another predefined formula to form Rb' and concatenates it 
with the client's initiating data, Le., the client initial packet 
sequence number and the encryption mode for the session, 
to form a second logon packet The client then masks the 
initial data with the random number Ra to hide the possibly lO 
known text encrypts die third logon packet and sends it to 
the server. Note that the client starts to send its initial data 
to the server only if the random number Ra* is verified to 
ensure that the server is a trusted party. 

After decrypting the third logon packet, the server also is 
manipulates the random number Rb with the same pre- 
defined formula used by the client and verifies if the random 
numbers are matched to assure that it communicates with a 
correct client If the random numbers match, the server 
knows that it is communicating with an authorized client and 20 
the first logon packet was not a replayed packet The server 
then saves the client initiating data, generates a session key 
Ks and an initialization vector IV with the fcnmula similar 
but more secure than the one specified in Appendix C of the 
ANSI X9.17 standard, encrypts and sends them to the client 25 
Along with the session key Ks and the IV, the server also 
sends its initiating data (i.e., the server initial packet 
sequence number, approved encryption or compression 
method). The client and server initial packet sequence 
nunlbers are used to detect packet deletion and insertion for 30 
data exchanged after the logon procedure. The server initial 
data is also masked with the dient random number Ra to 
hide possibly known text Note also that the server only 
sends its initial data after the number Rb is verified to ensure 
the dient is a valid party random number. 35 

After decrypting the third logon packet the client now 
saves the session key Ks and the IV in its own memory for 
future communication with the server. To improve 
performance, the cUent and server build encryption and 
decryption key sdiedules of s^DES and stores them in the 40 
session information block structure as shown in FIGS. 
5A-B. The S-boxes of s^DES are also combined with the 
P-box of DES algorithm to further enhance encryption 
speed. As described so far, the authentication tedmiques not 
only provide a secure identification procedure, but also a 45 
secure negotiation protocol to set up communication ses- 
sions (Le, encryption method, conqxression m^od, operat- 
ing platform, language, etc.). 

As appreciated, the following synibQls may hdp to clarify 
the logon procedure: 



1. A^B: EK(R)4BKa(Ra/(RaJ^UID))4BR(UlD) 

2. A<-B:EKb(Ra*Jlb) 

3. A->B: EKa(Rb'J>c) 

4. A<-B: EKb(IV45:s,Ds) 
where: 

A— a requester 
B — a server 

E — a symmetric cryptosystem sudi as DES or s^DES 
K— an encryption key generated from tiie server name 

R~~a 32'bit random number concatenated by a predefined 
constant 

Ka— a 192-bit key one-way hashed from flie user ID and 
password 

Ra — a 64-bit random value generated by A 

f( )— a hash function sudi as CRC to calculate the 

signature 
UID— auserlD 

Kb— a 192-bit one-way hashed key retrieved from a 

database 

ha( )— a hash function to manq)ulate the random number 

Ra 

Rb— a 64-bit random value g^erated by B 
hb( ) — a hash function to manipulate the random number 
Rb 

Do— client InMal data masked with Ra 
IV-— an initial chaining vector for encryption in CBC 
mode 

Ks — a session encryption key 

Ds— server initial data masked with Ra 

Ra'— ba(Ra) 

Rb'-4ib(Rb) 

After the logon procedure is conqdeted, the random 
numbers Ra and Rb are XOR*ed by both the client and 
server to generate a key for the S*boxes used by DES or 
s^DES. The key-d^endent S-boxes wiD make DES and 
s^DES harder to cryptanalyze since the key length is longer. 
Thus, every communication session will have a different 
session key and different S-boxes to be used by DES and 
s^DES in addition to the IV. 

Variants of the S-boxes, such as s^ES S-boxes can be 
used in place of DES S-boxes to provide in^oved security. 
An example of such S-boxes are included in Table 1, bdow. 
In table 1, the s^DES S-box 1 and S-box 2 are reversed fr<Hn 
an original s^DES S-box configuration. 
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TABLE 1-continucd 



4 13 1 8 7 2 14 11 15 10 12 3 9 5 0 6 
6 S 8 11 13 14 3 0 9 2 4 I 10 7 15 12 

S-box4: 

9 0 7 U 12 5 10 6 15 3 1 14 2 8 4 13 

5 10 12 6 0 15 3 9 8 13 11 1 7 2 14 4 
10 7 9 12 5 0 6 11 3 14 4 2 8 13 15 1 

3 9 15 0 6 10 5 12 14 2 1 7 13 4 8 .11 
S»box 5: 

5 IS 9 10 0 3 14 4 2 12 7 1 13 5 8 11 

6 9 3 15 5 12 0 10 8 7 13 4 2 11 14 1 
15 0 10 9 3 5 4 14 8 11 I 7 6 12 13 2 

12 5 0 6 15 10 9 3 7 2 14 11 8 1 4 13 
S-boi 6: 

4 3 7 10 9 0 14 13 IS 5 12 6 2 U 1 8 
14 13 11 4 2 7 1 8 9 10 S 3 15 0 12 6 

13 0 10 9 4 3 7 14 1 15 6 12 8 5 11 2 
1 7 4 14 11 8 13 2 10 12 3 5 6 15 0 9 

S4)Ox7: 



4 10 15 12 2 9 1 6 11 5 0 3 7 14 13 8 

10 15 6 0 5 3 12 9 1 8 11 13 14 4 7 2 

2 12 9 6 15 10 4 1 5 11 3 0 8 7 14 13 

12 6 3 9 0 5 10 15 2 13 4 14 7 11 1 8 
S-b03c8: 

13 10 0 7 3 9 14 4 2 15 12 1 5 6 11 8 
2 7 13 1 4 14 11 8 15 12 6 10 9 5 0 3 
4 13 14 0 9 3 7 10 1 8 2 11 15 5 12 6 
8 11 7 14 2 4 13 1 6 5 9 0 12 15 3 10 



The generated S-boxes can further be combined by the 
P-Box of the DBS algodthm speciiied in FIPS 41 to speed 
up the encryption process. These condensed SP-Boxes are 
stored in the memory as shown in FIGS. 5A and 5B. 

The s^DES ^cryption method disclosed above can be 
used in several alternative embodiments, each of which 
provides distinct advantages. For example, each client in a 
system can have its own set of s^DES S-boxes so that data 
is encrypted differently for each session. Thorefore, even if 
the s^ES S-box enayption table data was dedpheied for 
one client, the other clients would still be protected because 
their enaypted data are different 

Another method o£ improving security is accomplished by 
storing the s^ES S-box encryption table in alterable 
stwage, such as system memory, PROMs, EPROMs, ^c. 
The client and server can selectively update the s^ES 
S-box encryption table data between communication ses> 
sions or when otherwise convenient An advantage associ- 
ated with this technique is that since the system can change 
the s^DES S-box encryption table between communication 
sessions, the client is protected on subsequent logons from 
intruders who deciphered the s%ES S-box encryption table 
from the previous session. 

There are both legal restrictions and costs associated with 
the use of encryption codes. For example, U.S. law prohibits 
enayption techniques which are dif&cult to break from 
being exported to foreign countries. Likewise, the longer the 
encryption code, the more resources the code requires to 
decipher. By masking the leading bits in the session key to 
zero, the code can effectively be altered to shorter lengths. 
In addition to complying with U.S. law, this also allows the 
server to provide different security levels to different clients. 
For example, a domestic client may have a higher level code 
for data transmission within the United States while a 
foreign client would have a lower security level due to a 
masking of bits in the session key. 

The server can examine the source system identiiication 
provided by the client during the logon procedure. If the 



client requests an unauthorized security level the server can 
reset die security level to a pennitted level of security for 
that particular client 

Odier perfomoance enhancements can be realized by 
sending mult^le requests from a client system to a server in 
a smgle transmission. In addition, system performance can 
also be improved by preventing subsequent packet data from 
being transmitted between a server and a dient until the 
previous packet data has been responded to Requestors can 
^ batch application work within the client machine and com- 
municate with the remote server resulting in remote batch- 
ing. As a result, the requestor acts as a remote server 
function. Hiis function is done asynchronously to enhance 
performance. 

45 Finally, the communication subsystem of the prefened 
embodiments are a foundation for imiltiple applications 
when dieir uses are in demand. With just one communication 
session between a client and a server* packet sending can be 
initiated by either party to conduct file transfers, broadcast 

50 messages, or B-mail messages. In addition to minimum 
resources and maximum performance, security is also pro- 
vided to protect the secret of the data. 

The preferred embodiment envisions a security system 
based on s^DES S-box encryption, and for ease of 

55 discussion, s^DES S-box encryption was used in the fore- 
going discussion. However, alternative S-box encryption 
methods, such as DES S-box encryption, can be substituted. 

While the invention has been described with respect to a 
preferred embodiment thereof, it will be understood by those 

60 skilled in the art that various changes in detail may be made 
therein without departing from the spirit, scope, and teach- 
ing of the invention. For example, the size of encryption 
keys can be changed, algorithms used to generate the 
encryption keys can be changed, the device can be imple- 

65 mented in hardware or software, etc. Accordingly, the inven- 
tion herein disclosed is to be limited only as specified in the 
following claims. 
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I claim: 

1. A method of securely transmitting packet data between 
a client and a server with packets encrypted by S-box data, 
including the steps of: 

using at least one conmiunication channel to transmit 

packets between at least one client and a server; 
enaypdng in the dlent a first logon packet including 

infonuation identifying the client source system and 

transmitdng the first logon packet to the server, 
decrypting the first logon packet in the server; 
encrypting a second logon packet in the server with client 

authenticating information and transmitting the second 

logon packet to the client; 
decrypting the second logon packet in the client; 
encrypting in the client a third logon packet with session 

information and transmitting the second logon packet 

to the server; 
decrypting the third logon packet in the server; 
encrypting a fourth logon packet in die sorer widi session 

iiioimatton and transmitting the fourth logon packet to 

the client; and 
decrypting the fourth logon packet in the client; 
transmitting encrypted data packets between the dient 

and server which are encrypted using S-box encryption; 
whereby the client and server can establish secure com- 

municatiotts by bi-directionally transmitting encrypted 

data. 

2. A method, as in claim 1, wherein a plurality of clients 
are communicating with the server and each client's data 
packets are encrypted with a dififerent S-box table data. 

3. A method, as in claim 2, wherein a new S-box is 
selected for a client each time the client establishes a 
connection with the server. 

4. A method, as in claim 3, including the further steps of: 
storing the S-box encryption table data in updatable 

storage; 

selectively altering the S'tx>x data. 

5. A method as in claim 3, including the further steps of: 
using the S-box table in updatable storage to encrypt data; 
selectively altering the S-box data with a key diosen by 

both client and server. 

6. A method, as in claim 1, including the further steps of: 
storing the S-box encryption table data in updatable 

storage; 

selectively altering the S-box data. 

7. A method, as in claim 1, including the further steps of: 
using at least two selectable encryption schemes, includ- 
ing at least a first encryption sdieme for a first security 
level and at least a second encryption scheme for a 
second security level; and 

the server dctennines if the security level requested by a 
client is authorized and if the security level is 
unauthorized, ^e server reduces the security level to a 
permissible level. 

8. A method, as in daim 7, including the further steps of: 
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using the S-box table in updatable storage to encrypt data; 
selectively altering the S-box data with a key chosen by 
both client and server. 

9. A method, as in daim 7, wherein a plurality of clients 
^ are communicating with the server and each client's data 

padcets are encrypted witti different S-boxes. 

10. A method, as in daim 9, wherdn a new S-box is 
selected f<fr a communication session by both the client and 
the server each time the client establishes a connection with 
tiie server. 

11. A method, as in daim 10, induding the further steps 
of: 

storing the S-box encryption table data in updatable 
j5 storage; 

selectively altering the S-box data. 

12. A mediod, as in daim 10, including the further steps 
of: 

using the S-box table in updatable storage to encrypt data; 
20 selectively altering the S-box data with a key chosen by 
both client and server. 

13. A method, as in claim 9, wherein data packets from 
multiple clients are sent to the server in a single transmis- 
sion. 

25 14.AmBthod,asindaiml3,whaeinanews%£SS-box 
is sdected for a communication session by both the client 
and the server eadi time the dioit establishes a connection 
with the server; 

15. A method, as in daim 14, wherein succeeding data 
30 packets from a dient are continuously sent to the server via 

a write thread and responses firam the server are continu- 
ously reodved via a read thread. 

16. A method, as in claim 15, including the further st^s 
of: 

using the S-box table in updatable storage to enaypt data; 
selectively altering the S-box data with a key chosen by 
both client and server. 

17. A metiiod, as in daim 9, wherdn succeeding data 
^ pack^ from a dient are continuously sent to the server via 

a write thread and responses from the server are continu- 
ously recdved via a read thread. 

18. A method, as in daim 17, induding die further steps 
of: 

45 Storing the S-box encryption table data in updatable 

storage; 

selectively altering the S-box data. 

19. A method, as in claim 17, induding the further steps 
of: 

50 using the S-box table in updatable storage to encrypt data; 
selectively altering the S-box data with a key chosen by 
both client and servo:. 

20. A method, as in daim 1, induding the further steps of: 
using the S-box table in updatable storage to encrypt data; 
sdectivdy altering the S-box data with a key chosen by 

both client and server. 

Ht * * * * 
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User connects to Destination server (DS) 
through IIM and IIM records DS address in 
history database 
615 

Change reference to DS to go through IIM 
and to load in DSDA, maintaining WIA frame 
620 



Record user's 
communication 
with DS in user's 
transaction DB 





IIM forwards communication 
to DS Including relevant 
cookies 
635 



Yes 



Yes 



Fig. 6 




Record DS response 
in user's transaction 

DB 

645 



IIM instruments DS's response, 
stores cookies returned by DS, and 
forwards to client browser 
650 
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Parse code for next keyword 
725 




Fig. 7 
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Identify for field 
names 
1035 



Yes 



Fill in data from user profile 
1030 



Fill in changed information from profile 
1045 



Fill in remaining information as in 
transaction DB 
1050 



Display filling in form to user, and 
allow user to edit form 
1055 



User submits form 
1060 



C 1 ) 



Fig. 10 
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Privileged User connects 
to IIM 
1110 



Privileged user accesses page with forms on 
destination server through IIIM 
1120 



ilM displays user interface for 
cataloguing form 
1130 



I 



Privileged user maps each form 
element to an element in user profile 
object 
1140 



Privileged user adds other information 
about form 
1150 



Privileged user submits information to 
IIM 
1160 




r 


IIM updates form identification and 
form description in form OB 
1170 




r 




End 
1180 



Fig. 1 1 
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User connects to IIM 
1210 




User accesses a DS through account 
login page 
1220 



User requests to add account to 
account database 
1230 




Prompt user to complete 
login process 
1240 



Add account entry into user's account 
database, record account login information 
and date of account entry creation 
1245 



Submit account info to DS 
for login 
1250 




Fig. 12A 
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User connects to IIM 
1260 







User accesses Account Auto-login 
using Ui 
1265 




r 


User selects account to log into 
1270 




r 


IIIU retrieves login info from user'is 
account database 
1275 




f 


IIM sends login info to appropriate 
DS to log in user 
1280 




r 


IIM instruments DS response and 
sends it to user's browser for dis- 
play 
1285 




f 




End 
1290 




Fig. 12B 
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User accesses a page 
through Intermediary 
1310 



^y'^ Did user send ^^V^ 
user's e-mail 


Yes ^ 


Alter e-mail address to bifurcate 
such that responses go to user 


"^v. address? ^ 
1330 




and to IIM with transaction tag 
1340 


No 










< 

r 








Store information on transaction 
1350 










Yes 



Store response from server 
1370 



Add date, time, and other information stored to 
transaction 
1380 



Attach any notes, data, or e-mails received with 
transaction tag to transaction 
1390 



1395 ) 



Fig. 13 
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User accesses a OS page 
through IIM 
1510 




Fig. 15A 
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User requests access to 
bookmarks through Ul 
1540 



IIM generates a book- 
mark list from user's 
bookmark DB and sends 
to CB to display 
1545 



User selects a bookmark 
to access DS page 
1550 



i 

IIM fetches page URI 
from bookmark database 
1555 



IIM fetches DS page, In- 
struments data, and 
sends to client browser 
to display 
1560 




Fig. 15B 



08/09/2004, EAST Version: 1.4.1 



U^S. Patent Jan, 7, 2003 Sheet 19 of 25 US 6,505,230 Bl 




User connects to IIM 
1570 




User requests access to history through Ul 
1575 



IIM generates a history list from user's his- 
tory database and sends to CB to display 
1580 



User selects a list entry to access DS page 
1582 



IIM fetches page URI from history database 
1585 



IIM fetches OS page, instruments data, and 
sends to client browser to display 
1590 




Fig. 15C 
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Original Code 1 Attered Code I Comments 








<l>ase hrefs*anyURL'> 


<ba8e 

hrefs'httpyMww.OS.com/myDo 
cument.htmr> 

<Dase nreis anyuriL > 


www.OS.com Is the hostname 
of the OS. The IIM Inserts the 
first <BASE> tag line after the 
<HTML> tag and before the 
<ntAU> tag, ana Detore any 
existing <BASE> tags 


<form actions7actionURL"> 


SaveOrigAction( form. 
actionURL) 

<iWrm avUUil— 

http7/www. 1 IM .com/redirect?act 

shttp://www.DS.com 

/acttonURL"> 


www.IIM.com is the hostname 
of the IIM and www.OS.com is 
ine nosxname oi tne uo. 

Javascript function that saves 
the form's original action. 


<appiet codebasesVcodebase" 
code="applet.class"> 


<appiet codebases" 
http7/www.llM.com/redirect?cb 

http://www.OS.com/codebase'' 
code='applet.ciass"> 


www.IIM.com Is the hostname 
of the IIM and www.DS.com is 
the hostname of the OS. 


<frame src=7my Frame .htmr> 

otiiertags, e.g., <script>, 
<area>. <laver> , <img> 


<frame 

srcs^httpy/www.llM.com/redlre 
ct?src=http://www. DS.com/my F 
rame.html"> 


wwwJIM.com is the hostname 
of the MM and www.OS.com is 
the hostname of the OS. 








linlchrel = "newLocation" 


setURLProparty ( link, "href. 
"newLocatton" ) 


setURLPropertyO sets the 
value of the property href to the 
value 

**http://www.llM,com/redlrect?ur 
l=http://www.DS.com/newLocat 
ion", where www.IIM.com Is the 
hostname of the IIM and 
www.DS.com is the hostname 
of the OS. 


link.onclicl( s originalOnCIIck 


function 

addNewLinkOnclk:k(iink){ 
tink.onclickOrl9 = 

itnK.unciidv, 
link-ondick a 

newLinkOnclick; } 

function newLlnkOnclick(link){ 
if ( link.originalHref so null ) 
link.originalHref = nnk.href; 
var newHref = 

getFullPathName( 
llnk.originalHref ); 
link.href = 

http://www.IIM.com/redirect7url 
snewHref; 

return link.onclickOrig(): } 


getFullPathNameO returns the 
full pathname URL of the 
HTML and www.IIM.com is the 

ilOSUialTra OI ula IIM. i RB 

function addNewLinkOncUck() 
Is called when the HTML 
document Is first loaded 



Fig. 16A 
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Oriqinal Code 


Altered Code 


Comments 


docum8nt.write(StringToWnte) 


writeDocument ( document, 
StringToWrite ); 


writeDocumentO recursively 
modifies all HTTP control 
points that occur in 
StringToWrite 


window.open( newLocation ); 


openWindow ( window. 
newLocation ); 


openWindow calls 
window.openO with the 
argument 

''http://www.IS.com/redirect7uri 
=http://www.DS.com/newLocati 
on- 


form.onsubmit = 
origlnalOnSubmit 


function 

addNewFormOnsubmit(forni){ 
form.onsubmitOrig = 

form.onsubmit; 
fonfn.onsubmlt = 

newFonmOnsubmit; } 

function 

newFormOnsubmit ( form ) { 
if (forni.originalAction = null) 
{form.origlnalAction s 
fonn.action;} 

var newAction = 

getFullPathName(fomfi.original 

Action); 

forTn.action s 

http:/Afvww.llMxom/redirect?urt 
«newAction; 

return form.onsubmitOrig(); } 


getFullPathNameO returns the 
full pathname URL of the 
HTML document and 
www.IIM.com Is the hostname 
of the IIM. The function 
addNewFomnOnsubmitO is 
called when the HTML 
document is first loaded 








class iava.netSocket 


Extends java.net.Socket and 
ovenides various constructors. 


The extended method modifies 
the host and port arguments. 
The modified host argument is 
the hostname of the IIM. The 
modified port argument is the 
port of the IIM 


java.applet.AppletContext 


Extends 

java.applet.AppletContext and 
overrides various constructors 


The extended method modifies 
the uri argument. The modified 
urt sends the HTTP request to 
the IIM with the full pathname 
of the original uri as a query 
parameter 


class java.appiet.Appl6t 


Extends java.applet.Applet and 
ovenides various constmctors 


The extended method modifies 
the uri argument. The modified 
urt sends the HTTP request to 
the IIM with the full pathname 
of the original uri as a query 
parameter 



Fig. 16B 
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Original Code | AKered Code 


Comments 


HTTP Headers^v^'r: -.^^^'v*'^^.^•^^^.'■:<y:^^^ ^.^i^-^^ri^^:^ 




referer, 

e.g. value = origDochtm 


referer, 

http://Www.DS.com/origDoc.ht 
m 


referer value is replaced with 
the full pathname of the 
document's original URL 


content-type, 
value = null 


content-type, 

e.g., value = Image/gif 


If the value of content-type is 
null, the IIM sets this header to 
a value that describes the type 
of content contained in the 
document. 


refresh, 
e.g. 

5000; origDoc.htm 


5000; 

http'7/www.lS.com/redirect?refs 

http://Www.DS.com/origDoc.ht 

m 


IIM replaces the URL portion of 
the value of the refresh header 
with the full pathname of the 
docunrYenf s original URL 


301 , 302 status codes, 

e.g.. URt value = 

http://www.DS.com/origDoc.ht 

ml 


301 . 302 status codes, 
URI value = 

http://www.IS.com/rsdirect7uria 

http://Www.DS.com/origDoc.ht 

ml 


www.IIM.com is the hostname 
of the IIM 


201 , 303, 305, 307 Status 
codes 

URI values 


201.303, 305. 307 status 
codes 

modified URI values 


See 301 . 302 status codes 



Fig. 16C 
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Original Code 


Altered Code 


Comments 


HTML ■ . ::A^ -:::'rOt-i']i^^y:^:^m^ 






target = " Jop" 

for <a hr8f>, <frame>, <forrn> 
arKi <base> tags 


target = "DSFranrieName" 


where DSFrameName is the 
name of the DSDA top frame. 


target = ".parent" 

for <a href>, <frame>, <form> 
and <base> tags 


target = "DSFrameName' 


where DSFrameName is the 
name of the DSDA top frame, if 
the current window evaluates 
to the DSDA top frame. 






top.iocationProperty » vaiue 


setTopProperty ( 
currentWindow, 
tocationProperty, value ) 


setTopProperty sets a location 
property on the DSDA top 
frame with name 
locationProperty to have value 
value 


window.parent. 
locationProperty = value 


setTopProperty ( 
window.parent. 
locationProperty, value ) 


setTopProperty sets a location 
property on the DSDA top 
frame with name 
locationProperty to have value 
value if window.parent 
evaluates to the top or MM 
frame 


Java: \^^^^^]^^!>k-m^mmi^^>^^^ 






java.applet.AppletContext.show 
Document( uri, target ) 


newShowDocument ( window, 

uri. target ) 

{ 

java.appletAppletContext.show 
Document( urI, newTarget ) 
) 


newShowDocument calls 
java.applet.AppletContext.show 
Document where newTarget Is 
the name of the DSDA frame if 
target equals "_top" or if target 
equals "^arenf and window is 
the DSDA frame, "newTargef 
is set to larger othenvise. 



Fig. 17 
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Original Code 


Altered Code 


Comnrtents 


Jiavascript:^-:'.. .v-u-; :':;*• r;-::cK; 






string = document.cookie 


string = getCookie( window, 
document ) 


getCookieO gets the cookie's 
value from the IIM and assigns 
the value to string 


cookieString 


cookieString) 


setCookie() sends the value of 
cookieString to the IIM to be 
managed 


HTrP;Headc»rsr:.^ -^/i^rgi^sKi^ 








cookie 


MM sends this header to the OS 
on a need basis 








javax.s6rvldt.http.Cookle 


public class ISCookie 
innpleniients Seriallzable { 1 

private long _creatk)nTime; 

public boolean hasExpired(){ 
// expiration function code } 
} 


maintains the cookie's creation 
time and contains convenience 
routines that determine If the 
cookie has expired 


Cookies 


public class Cookies extends 
PerststentObject inriplenients 
Seriallzable ( 

public string getuookie (URL 
uri){) 

public static Cookie 
parseCookie(String str) { } 

public void 

addCookie(ISCookie coo, URL 
urt){) 

private boolean 

valtdCookie(ISCookle coo, URL 

url){} 

} 


extends the Java persistent 
object class, and saves in a 
user database the user-specific 
cookie information that the OS 
sent In the set-cookie header 
This class also finds the 
cookies in the cookie database 
that are valid for a certain URI 
based on welt known Cookie 
rules and returns a Cookie 
string for a given URI. 



Fig. 18 
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Original Code I Altered Code I Comments 




window.location s newLocatton 


setLocation(cuiTentWindow, 
window, newLocation) 


setLocationO sets the 
window.location to the value 
''http'y/www.llM.com/redirect?ur 
|ahttp://Www.DS.corTVnewLocat 
ion", where www.IIM.com is the 
hostname of the IIM and 
www.DS.com is the hostname 
of the DS. 


saveLocation ^ 
wtndowJocation 


saveLocation ^ 

getLocatk>n(cunrentVVindow, 

window) 


where getLocation returns 
window.location except when 
window is equal to the top 
frame, then it returns the DSDA 
top frame's location 


top.userProperty = value 


setTopProperty ( 
currentWindow, userProperty, 
value) 


where setTopProperty sets a 
user property on the DSDA top 
frame with name userProperty 
to have value value 


window.parentuserProperty » 
value 


setTopProperty ( 
window.parent, userProperty, 
value) 


where setTopProperty sets a 
user property on the DSDA top 
frame with name userProperty 
to have value value if 
window.parent evaluates to the 
top frame. 



Fig. 19 
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1 2 

CLIENT-SERVER INDEPENDENT may include fonns for requesting further information, for 

INTERMEDIARY MECHANISM ordering items from the Web, for registering for a Web site, 

etc. However, the user generally can not get a copy of the 
information filled into the fonn. The user can either print the 

FIELD OF THE INVENTION 5 page when the form is filled in, generating a paper copy, or 

rely on the server to respond in a manner that permits the 

The present invention relates to client-server user to make a record of the information entered in to the 

communication, and more specificaUy, to using an indepen- form. A method of tracking information filled into forms 

dent intermediary mechanism between a client and a server. would be advantageous. Furthermore, vendors may respond 

n Ari^roni TMn 10 ^^^^ ^° ^^^^^ number or other useful information. The user 

BACKGROUND j^^^p ^ p2Lg&^ which is generally only 

The World-Wide Web (WWW, W3, the Web) is an temporarily available, by printing it, or copying down the 

Internet client-server hypertext distributed information information provided. A method of attaching this vendor 

retrieval system. An extensive user community has devel- response to the original order information and making both 

oped on the Web since its introduction. 15 available to the user would be advantageous. 

no. 1 is a block diagram of a prior art cHent-server Furthermore, currently, the user has to fill out each of 

system. The client A 110 can access destination servers ^^^^ ^^^^^ separately. Generally, the forms request the 

DS1-DS3 150-170. Similarly, other cHents B and C, 120 ^ypes of information, i.e. name, address, telephone 

130, can access the destination servers DSl-3 150-170. Each number, e-maU address, etc. The user has to enter all of this 

destination server may provide different services, 20 information for each form. This is repetitious and takes time, 

information, or other data to the user. Additionally, if such information as credit card number or 

*u «/ u ^u- ♦ ■ J- \ • social security number is requested, the user has to pull out 
On the Web everythmg (documents, menus, indices) is j * j j t . • c ^^• 
, . , ^ \ ^ ♦ u- ♦ • u J * the credit card and copy a long string of numbers. This 
represented to the user as hypertext objects in hypertext , 11 1 1- *i. u * c .t. . 

^ . 1 /Ti^MT \ e . T makes errors likely. Furthermore, the user has to verify that 

markup language (HTML) format, or as Java, or JavaScript „, u * * j-. j l • -i 

u- * *u J * * II * 1- 1 c » *u a Web site that requests a credit card number or similar 

objects, or other data types. Hypertext links refer to other 25 ^.,^^'c ■ r*i. • . 1 1 r 

J * u *u • / J /iTni \ Tn, confidential mformation IS of the appropriate level of secu- 

documents by their umform resource identifiers (URIs). The •* p »u ♦pi r .* ui *u • r 

, I . ^./-c ax/ "ty for the user to feel comfortable sendmg the information 

client program, known as a browser, e.g. NCSA Mosaic, 1_ * • j j u r- 

XT * KT • * *u f ♦ J over the Web. An improved method of fillmg out forms 

Netscape Navigator, runs on the user s computer and pro- u i_ j * 

'A u ' ' *• * r 11 1- I * would be advantageous, 

vides two basic navigation operations: to follow a link or to ^ 

send a query to a server. Users access the web through these 30 SUMMARY OF THE INVENTION 

browsers. ^ method and apparatus of a client-server independent 

Users often access the web firom multiple locations. Users intermediary mechanian (IIM) is described. The method 

may access the web from their office, at different locations comprises displaying a &ame including a user interface of 

at work, at home, or on the road. Libraries and Internet cafes the IIM (IIM frame), and a second frame framing a desti- 

make web access available on a walk-in basis as well. nation server display area (DSD A). The method further 

A user accesses a server by typing the URI of the server comprises retrieving data for display from a destination 

into the browser*s address window. The browser then con- server, and instrumenting the data prior to display such that 

nects to the server corresponding to this URI. Another future data retrieved from a destination server is displayed in 

method of accessing a web site is by selecting the web site the DSDA, without writing over the IIM frame, 

from list of bookmarks. The list of bookmarks is resident in BRIEF DESCRIPTION OF THE DRAWINGS 

the browser in the user's computer. Thus, if a user wishes to ^ . . . .„ 

have similar bookmarks on multiple computers, he or she P« P^^^sent mvention is illustrated by way of example, 

must manually copy the bookmarks and transfer them and not byway of limitation, in the figures of the accompa- 

between the computers. This process is inconvenient. °yi°g drawings and in which like reference numerals refer 

„ ^, 1 • . . • r ^5 to similar elements and in which: 

Furthermore, many servers use cookies to store informa- r.,^ ^ • , 

tion about the user. This information may include the user * " °^ P""^ chenl-server 

name, password, previous interests, etc. These cookies are system. 

also stored in the user's browser. Again, this means that if P^^- ^ is a block diagram of one embodiment of the 

the user is accessing the Internet from muhiple computers, 50 cUem-server system including the independent intermediary 

the user's cookies have to be duplicated into multiple mechanism. 

computers. This process is inconvenient. P^G. 3 A is a block diagram of one embodiment of the 
Many users have multiple accounts on different computer client-server system including multiple independent inter- 
systems. For example, a user may have an account with a mediary mechanisms. 

bank, an e-mail account, a personalized portal site account, 55 P'^- a block diagram of another embodiment of the 
and an account on an e-commerce server. Currently, the client-server system including multiple independent inter- 
users must log into each of these accounts by remembering mediary mechanisms. 

and providing his or her user name and password. For FIG- 4 is a block diagram of one embodiment of the 

security, each of these user names and passwords should be independent intermediary mechanism, 

different. Remembering different names and passwords is go FIG. 5 is a block diagram of one embodiment of the layout 

inconvenient to the user. Thus, a method for a simple log-in of the user interface of the independent intermediary mecha- 

into various accounts fi"om any computer would be advan- nism. 

tageous. FIG. 6 is a flowchart of an overview of using the inde- 

Most clients and servers support "forms" which allow the pendent intermediary mechanism, 

user to enter arbiUrary text as well as selecting options from 65 FIG. 7 is a flowchart of one embodiment of the process of 

customizable menus and on/off switches. As more business displaying information from a destination server through the 

is transacted on the Web, forms are proliferating. The forms independent intermediary mechanism. 
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FIG. 8 illustrates one embodiment of the user interface of For one embodiment, the client component 230 is estab- 

the independent intermediary mechanism. lished on the local computer of the client 210. For another 

FIG. 9 illustrates another embodiment of the user inter- embodiment, the client component 230 is on a server, or on 

face of the independent intermediary mechanism. a third computer system. The client component 230 is 

HG. 10 is a flowchart of one embodiment of the form fill ^ created in response to the client 210 connecting to the IIM 
functionality. 

FIG. 11 is a flowchart of one embodiment of the learning Th^ client A 210 has a connection to the server component 

process in the database through the client component 230. For one embodiment, 

HG. 12A is a flowchart of one embodiment of adding client A210 also establishes a direct connection with the 

accounts server component 260. This direct connection may be used 

^-^T^ - . ^ r , J- ^ to communicate certain information directly between the 

FIG. 12B ^ a flowchart of one embodiment of accessing ^^^^ component 260 and the client A 210. The cUent 210 

an account through an auto-log-in feature. ^^^^ destination servers DSl-3 280, 285, 290 

HG, 13 is a flowchart of one embodunent of the trans- through the IIM 250. For one embodiment, aU of the 

action management fimctionaUty. 15 communication between the destination server DSl 280 and 

FIG. 14 illustrates one embodiment of the listing of the client A 210 is routed through the IIM 250. For another 

transactions. embodiment, certain communications are routed directly 

FIG. 15A is a flowchart of one embodiment of selection between the client A 210 and the destination server 280. For 

of a home page or a bookmark. example, certain large images that do not invoke other 

FIG. 15B is a flowchart of one embodiment of using the images or other data may be routed directly in order to speed 

bookmark functionality. up processing. 

FIG. 15C is a flowchart of one embodiment of using, the The number of client components 230, 235, 240 depends 

history functionality. on the number of clients 210, 215, 220 coupled to the server 

FIGS. 16A, 16B and 16C are tables illustrating examples . component 260 at any one time. For one embodiment, the 

of redirecting references to DS through IIM. server component 260 consists of multiple components that 

HG. 17 is a table iUustrating examples of making the IIM act together. A block diagram of one embodiment of the IIM 

user interface frame persistent. ^50 may be found in FIG. 4, below. 

HG. 18 is a table illustrating examples of accessing , P"^- 3A is a block diagram of one embodiment of the 

cookies from the 30 chent-server system includmg multiple independent inter- 

HG. 19 is a table illustrating examples of preserving top P"^'!^''^ mechanisms 350. 360. Each IIM 350 360 k diown 

frame or IIM frame integrity for DS havmg a con^sponding server componenOSS 365. For 

^ ' another embodiment, the server components 355, 365 may 

DETAILED DESCRIPTION be located on a single server, or within a single IIM. Having 

A client-server independent intermediary mechanism is 35 server components 355, 365 coupled together may serve 

described. The independent intermediary mechanism (IIM) multiple purposes. For example, if a single IIM 350 has too 

mediates information exchanged between a client and serv- many users connected to it, the IIM 350 may redirect users 

QTS by having the client-server communication pass through ^ second IIM 360. For another embodiment, a user may 

the IIM. This allows the IIM to offer various services. For log on to a local IIM 350, for speed reasons, and the local 

one embodiment, the IIM may be used to have a central 40 350 may connect to the user's "home" IIM 360 to 

web-accessible set of bookmarks. The IIM may further retrieve the user's data. For yet another embodiment, the 

provide tracking of transactions on the web, providing a user can connect to their "home" IIM 350, which is remote, 

user-accessible transaction record. The IIM may further be and the "home" IIM 350 may redirect the user to a local IIM 

used to fill in various forms automatically. The IIM may and send the user's data to the local IIM 360. In this 

further be used to access multiple accounts, such as e-maU 45 w*y» ^® user's connection to the IIM 350, 360 may be 

accounts, bank accounts, etc. with a single button. The IIM optimized. 

may further be used to store the user's profile, including FIG. 3B is a block diagram of another embodiment of the 

passwords to various pages, etc. These and other uses of the client-server system including multiple independent inter- 

IIM are described below. mediary mechanisms. In this example, a client 310 is 

FIG. 2 is a block diagram of one embodiment of the 50 coupled to two IIMs 350, 360. Generally, the client 310 first 

client-server system including the independent intermediary connects to the first IIM 350. Then, through the user 

mechanism. Multiple clients A-C 210, 215, 220 access interface of the first IIM, the client 310 connects to the 

multiple destination servers (DSs) 280, 285, 290, through second IIM 360. This may be advantageous if, for example, 

the independent intermediary mechanism (IIM) 250. Client the first IIM 350 and second IIM 360 provide different 

A 210 is described as an example. It is to be understood that 55 services. Thus, for example, one IIM 360 may provide 

multiple clients are implemented in similar ways. additional account management feaUJres, while the other 

aient A 210 accesses the IIM 250. For one embodiment, HM 350 provides form-fill feanires. By connecting to both 

this occurs when the user of the client A 210 accesses the IIMs 350, 360, in series, the user has access to the features 

web site hosting the IIM 250. When the IIM 250 is accessed, provided by both IIMs 350, 360. 

a new client component (CC) 230 is established. The client 60 FIG. 4 is a block diagram of one embodiment of the 

component(s) 230, 235, 240 and the server component 260 independent intermediary mechanism. The IIM 400 has 

together form the IIM 250. For one embodiment, the IIM three layers. The lowest layer of the IIM 400 is the core 

250 is located on a server accessed by the client A 210 engine 410. The core engine 410 includes a server compo- 

through an Internet connection. For another embodiment, nent SC and a client component CC. The Server Component, 

the IIM 250 is located within the local Intranet of client A 65 for one embodiment, is resident on the server, and bandies 

210. For yet another embodiment, the IlM 250 is located on all remote actions. The Client Component, for one 

the client's own computer. embodiment, is resident on the client's system, while the 
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client is connected to the IIM 400. For one embodiment, the As can be seen, the IIM provides multiple functionalities, 

client component is automatically removed from the client's A single IIM 400 may include all of the functionalities 

system when the client disconnects from the IIM 400. The described above, additional functionalities, or some subset 

lowest layer also includes a Cookie Manager 413. for of these functionalities. The IIM's functionality may be 
managing any cookies received from and being sent to the 5 extended with additional features, 

destination server. The use of such cookies is discussed in m/^ < „ ui^^u j- u j- * r»u 1 

more detail below. Furthermore, the lowest layer may .ffuf^^.l^!, ^^^^^^^^ 

include a Activation Manager 416. The Activation Manager "i^' ^°;.^^^f mtermediary mecha- 

416 determines if inform^ion is being transmitted by The T""'^^" u apphcation window 510 is dis- 

destination server. For one embodiment, the Activation pI^^^^ browser, such as Netscape Navigator or 

Manager 416 further determines if information is being Microsoft Internet Explorer. The cUent side display area 

initiated by a user's action. Information transmitted between (CSDA) 520 is the display area available in the browser 

the DS and the client is instrumented by the IIM 400, as will application window 510. Most browsers have a toolbar and 

be described below. The Activation Manager 416 detects o^^r displays within the browser application window 510. 

when the IIM 400 should review communication between For one embodiment, the IIM is designed to minimize the 

the client and the DS, area of the browser application window that is not the CSDA 

The second layer is the applicationAJI framework layer ^2®- 

420. The application/UI framework layer 420 establishes the The CSDA 520 includes a toolbar frame 530. Although 

basic user interface and IIM engine. The applicationAJI tool bar frame 530 is referred to as a frame, for one 

framework layer 420 creates a persistent frame for the IIM embodiment, the tool bar frame 530 may be implemented in 

400. For one embodiment, the appUcation/UI framework a non-frame format. For one embodiment, the tool bar may 

layer 420 further includes an instrumenting manager 425, be implemented as a separate window. For another 

for instrumenting data flowing from the destination server to embodiment, the tool bar may be implemented as part of the 

the client, through the IIM 400. This process of instrument- display, not as a frame. 

ing is described in more detail below. The CSDA 520 further includes a destination server 

The third layer is the applications layer. The apphcations display area (DSDA) 540. The DSDA 540 is the area in. 

layer includes multiple applications. The applications listed which all information from destination servers is presented, 

here are listed as an example, and are not a complete list. The The CSDA 520 further includes a communications frame 

applications layer, for example, may include a Navigation 550. TTie communications frame 550 is for communication 

Manager 430. The Navigation Manager 430 permits a user between the client side and server side of the IIM. Generally, 

to navigate from destination server to destination server the communications frame 550 is hidden from the user's 

using the IIM 400. The applications layer may further view. Thus, the user would not see the communication 

include a Transaction Manager 440, between the client component and the server component. 

The Transaction Manager 440 tracks the user's FIG. 6.is a flowchart of an overview of using the inde- 

transactions, stores them, and makes them available for the pendent intermediary mechanism. At block 610, the user 

user's review. Transactions are interactions in which a user connects to the IIM through the chent browser For one 

submits information to a destination server, for example to embodiment, this is done by typing the address of the IIM 

order an item, ask a question, or otherwise interact with the into the address window of the browser. For one 

destination server. The Transaction Manager 440 tracks the embodiment, the IIM may be the preset homepage of the 

data submitted by the user, and any response from the user, or a bookmark in the client browser, 

destination server, and permits the user to access this infor- At block 615, the user connects to a destination server 

(DS) through the IIM. For one embodiment, this is done by 

The Account Manager 450 permits the user to log into a typing the address of the destination server into the address 

variety of accounts, from, e-mail to stock trading accounts, window of the IIM. For another embodiment, the user may 
using a single click. The Account Manager 450 further 45 select an address from a history list of previously visited 

permits the user to add accounts to this list. The Form sites, from a bookmark list in the IIM, or the destination 

Manager 460 permits the user to fill out forms encountered server may be a preset homepage in the IIM. The IIM 

on destination servers via a single click. This is extremely records the DS in the history database. The history database 

useful for users that transact business on the web, and often tracks the web sites that the user has visited in the past. Such 

fill out identical forms many times. The Profile Manager 470 a history database may be useful to permit backtracking, or 

is the database of the user's personal information. This to visit previously visited sites. For one embodiment, this 

information may be edited by the user, and is used to fill in history database is maintained for a fixed duration of time, 

forms via the form manager 460. The Database Manager 480 or a user preset period of time. For another embodiment, the 

manages the various databases of the IIM 400. history daubase is maintained indefinitely. 

The Bookmark Manager 490 permits the user to manage 55 At block 620, the process changes the reference to DS to 

bookmarks maintained within the IIM 400. Having go through the IIM and load the information from the DS in 

bookmarks, URIs of pages the user wishes to save, available the DSDA, maintaining the IIM frame. This is described in 

in the. IIM 400 permits the user to access his or her more detail below. 

bookmark list from any computer. At block 625, the IIM determines whether the user 
The History Manager 495 permits the user to manipulate 60 submitted information to the destination server. For one 

the history list of sites the user has previously visited. For embodiment, the actual test is whether information that is 

oneembodiment, the user can change the permanence of the "sensitive" or "of interest" is submitted to the DS. For 

history lists, for another embodiment, the user can delete example, if a user selected a radio button for the next 

certain sites, from the history list. display, the response would be "no" even though some 
The Homepage Manager 497 permits the user to set a 65 information was submitted. For one embodiment, the answer 

homepage that is displayed when the user initially connects to this query is yes only if information that is in the user's 

to the server providing the IIM 400. profile is submitted. For one embodiment, the answer to this 
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query is provided by the user through the user interface. If 
the answer is yes, the process continues to block 630. 

At block 630, the user's communication with the DS is 
recorded in the user's transaction database. For example, if 
the user ordered an item from a destination server site, the 5 
form that was filled in by the user, including all of the 
information filled in, would be recorded in the transaction 
database. This transaction database is available to the user. 
The process then continues to block 635. If, at block 625, the 
answer was no, the process continues directly to block 635. 

At block 635, the IIM forwards the communication, i.e. 
the information submitted by the user, to the DS. This 
communication includes relevant cookies. A cookie is a 
packet of information sent by a destination server to a 
browser and then sent back by the browser each time it 
accesses that server. Cookies can contain any arbitrary 
information the server chooses and they are used to maintain 
state between otherwise stateless transactions. Generally, 
cookies are maintained in a user's browser. However, for 
one embodiment, the IIM maintains the user's cookies. This 
permits a user to log into a site, and have the appropriate 
cookies available, no matter from what web client device or 
client browser the user accesses the site. 

At block 640, the process determines whether the desti- 
nation server responded to the user's submission of infor- 
mation. For one embodiment, some destination servers 
respond, with a thank you page, other data pertaining to 
order number, shipping code, delivery date, etc., when 
information is submitted to them. If the destination server 
responds at block 640, the process continues to block 645. 

At block 645, the DS's response is recorded in the user's 
transaction database, and associated with the user's submit- 
ted information. Thus, when the user reviews the 
transaction, he or she can review the entire transaction, 
including the DS's response. 

At block 650, the IIM instruments the DS's response, 
stores any cookies returned by the DS, and forwards the 
response to the client browser. One embodiment of this 
process is illustrated in more detail in FIG. 7, below. Tables 
of some results of the process of instrumenting are illus- 
trated in FIGS. 16A-C, and HGS. 17-19. 

At block 655, the process tests whether the user continues 
to browse through the IIM. The user continues to browse, the 
process returns to block 615. Otherwise, the process ends at 
block 660. 45 

FIG. 7 is a flowchart of one embodiment of the process of 
instrumenting data displayed from a destination server 
through the independent intermediary mechanism. For one 
embodiment, FIG. 7 is a more detailed flowchart of block 
650, in FIG. 6. At block 705, the IIM receives a communi- so 
cation from the DS. For one embodiment, this occurs in 
response to a user contacting a DS through the IIM. 

At block 710, the process tests whether there is a cookie 
or multiple cookies associated with the communication. 
Cookies may be sent by the DS to the client, to be stored on 55 
the client browser. If a cookie is associated with the 
communication, the process continues to block 715. At 
block 715, the IIM cookie database is updated with the new 
cookie. For one embodiment, cookies sent by the DS to the 
client browser are handled through the IIM. Thus, the IIM 60 
would store all of the cookies for a DS, and give the DS its 
cookies. This is advantageous because it permits a user to 
access a DS from any computer, and all of the user's cookies 
are immediately available through the IIM. The process then 
continues to block 725. If no cookies were associated with 65 
the communication, the process continues directly to block 
725. 
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At block 725, the process parses the code to find the next 
keyword. For one embodiment, keywords are tags in 
HTML, or known keywords in Java or JavaScript. FIGS. 
16-19 illustrate some examples of keywords that may 
trigger this process. For another embodiment, keywords may 
be any triggering signal that indicates that an action may be 
performed. 

At block 730, the process tests whether a keyword was 
found. If no keyword was found, the process continues to 
block 735, and ends. If the communication has no remaining 
keywords, the document has been fully instrumented, and is 
ready for display to the user. For one embodiment, certain 
communications may have no keywords at all. In that case, 
this process would end after a single pass. For yet another 
embodiment, under some circimistanoes, the process may 
ignore certain keywords. Certain references are not altered 
in the communication. For example, references that call 
static images, images that do not communicate information 
to the user and do not have embedded references, may be of 
no interest. For example, if the keyword calls a large passive 
figure with multiple components, the process may ignore the 
entire figure, by tagging figure related communications, and 
exit out of this process even if keywords remain. By altering 
only those references that are of interest, the process may be 
sped up. If a keyword was found, the process continues to 
block 740. 

At block, 740, the process tests whether the keyword is an 
attempt to access a cookie from the cookie database. If the 
kejrword is an attempt to access a cookie, the process 
continues to block 745. At block 745, the access attempt is 
changed to fetch the cookie from the IIM's cookie database. 
Some examples of this process are provided in FIG. 18. For 
one embodiment, the IIM's cookie database may access the 
client browser's cookie database in order to determine 
whether there are additional cookies on the client browser. 
For one embodiment, the IIM can, with the user's 
permission, copy cookies from the browser cookie database 
to the DM. This simplifies moving from direct access of a 
DS to accessing a DS through the IIM. The process then 
continues to block 750. 

If the keyword is not an attempt to access a cookie, the 
process continues directly to block 750. 

At block 750, the process tests whether the keyword is an 
attempt to access the top frame or IIM frame. If the keyword 
is an attempt to access the top frame or IIM frame, the 
process continues to block 755. At block 755, the access 
attempt is changed to access the top area of the destination 
server display area (DSD A). Some examples of this process 
are provided in FIG. 17. The process then continues to block 
760. 

If the keyword is not an attempt to access the top of IIM 
frame, the process continues directly to block 760. 

At block 760, the process tests whether the keyword is a 
reference to the destination server. If the keyword is a 
reference to the destination server, the process continues to 
block 765. At block 765, the reference is changed to be 
fetched through the IIM. Some examples of this process are 
provided in FIGS. 16A-C. The process then continues to 
block 770. 

If the keyword is not a reference to the destination server, 
the process continues directly to block 770. 

At block 770, the process tests whether the keyword is an 
attempt to access data from the top frame or IIM frame. If 
the keyword is an attempt to access data from the top frame 
or IIM frame, the process continues to block 775. At block 
775, the access attempt is changed to fetch data from the 
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topmost frame of the DSD A. Some examples of this process 
are provided in FIG. 19. The process then returns to block 
725, and parses to find the next keyword. 

For one embodiment, the above process may be triggered 
by a user. For example, a user may select a link, activate a 
JavaScript function, or otherwise initiate communication 
between the destination server and the client. The same 
process may occur in response to a cookie being sent or 
received, or a keyword being found as described above with 
respect to FIG. 7, 

FIG. 8 illustrates one embodiment of the user interface of 
the independent intermediary mechanism. The user interface 
includes a browser toolbar 805. For one embodiment, the 
IIM may configure the browser such that the browser toolbar 
area 805 is not displayed when the IIM is active The display 
area 810 of the browser includes the IIM toolbar 820, a 
hidden communications frame 815, and the destination 
server display area 845. 

The IIM toolbar 820 includes the known browser controls 
825, such as back, forward, refresh, stop, etc. Additional 
browser controls 825 may be added. The toolbar 820 further 
includes an address entry control 830, where a user can type 
a destination server address in order to access the DS. 

The IIM toolbar 820 may further include buttons, or other 
selection mechanisms that permit a user to configure and use 
the IIM. The buttons may include Home, selecting a user's 
preset homepage, etc. The homepage is preset using the Set 
Home button 852. The buttons may further include the Mall 
button, giving one-button access to shopping. The buttons 
may further include Tags 860, displaying a list of a user's 
bookmarks. Bookmarks are added by selecting the Tag 
Address while visiting a web site, or by selecting the Tag 
Address button 862, and typing the address of a location to 
be bookmarked. 

The buttons may further include Accounts 865, permitting 
single-button log-on to a variety of accounts. These accounts 
are added with the Add Account button 867, as will be 
described below. 

The buttons may also include a Transactions button 870, 
that permits a user to review his or her transactions. This is 
illustrated in the destination server display area 845 of FIG. 
8. The Profile button 875 permits the user to enter his or her 
personal data. The Fill-Form button 880 permits the user to 
fill in a form using the personal data from the user's profile 
or by using information submitted previously using the same 
form. If a form is displayed on the destination server display 
area 845, and the user selects the fill-form button 880, the 
form is automatically filled in with the user's information. 
The Clear Form button 882 permits a user to remove the 
information filled into a form. This provides an additional 
level of security to the user. 

The Admin button 885 provides access to account admin- 
istration services. For one embodiment, the Admin button 
885 is only available to those users who are authorized 
administrators. For one embodiment, the Admin button 885 
is only displayed if the user is authorized to access account 
administration services. 

The toolbar 820 further includes a Bye button 890, which 
logs off the user from the IIM. The toolbar 820 illustrated is 
exemplary. The content and organization of the buttons on 
the toolbar 820 may be changed without changing the 
invention. 

FIG. 9 illustrates another embodiment of the user inter- 
face of the independent intermediary mechanism. As can be 
seen, the user interface may be flexibly implemented. Cer- 
tain features may be provided by one interface and not 
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provided by another. Furthermore, the look and feel of the 
user interface may be altered. The user may, for example, 
access all of the IIM features through pull-down menus, 
such as the pull-down menu 935, or radio buttons instead of 

5 buttons. One skilled in the art understands other types of 
user interface changes that may be made without departing 
&om the broader spirit and scope of the invention as set forth 
in the appended claims. 

FIG. 10 is a flowchart of one embodiment of the form fill 

jQ functionality. At block 1010, a document with a foraa is 
displayed. For one embodiment, this is a result of a user 
accessing a destination server location that includes a form. 
This form may be an order form, an information request 
form, or any other form that may be encoimtered on the Web. 

At block 1015, the user requests the form-fill function 
through the IIM user interface. For one embodiment, the 
user presses the form-fill button. For another embodiment, 
the form fill may be automated. For yet another 
embodiment, the user can select whether the form fill 
function is automatically engaged. 

At block 1020, the process determines whether the form 
is in the user's transaction database. The user's transaction 
database has records of previously accessed and filled-in 
forms for the particular user. The transaction database may 
maintain such records for a limited time, or the user may 

25 delete transaction records. Thus, merely because a user has 
been to a particular site previously may not mean that the 
form is in the user's transaction database. If the form is in 
the user's transaction database, the process continues to 
block 1040, otherwise, the process continues to block 1025. 

30 At block 1025, the process determines whether the form 
is in the form database. The form database is maintained by 
the IIM and includes "known" forms. Such known forms 
have associations between form control identifiers in the 
form and profile items. Thus, for example, a form control 

35 identifier that is labeled "name" may have a link to the "First 
Name Last Name" item in the user profile. If the form is 
known, the process continues to block 1030. At block 1030, 
the form control identifiers in the form are filled in from the 
user profile. The process then returns to block 1055. 

4g If the form is not known, the process continues to block 
1035. At block 1035, the form controls are identified, based 
on the name of each control. Each control name is associated 
with entries in the user profile. The process then continues 
to block 1030, and the data is filled into the form from the 

45 user profile. For one embodiment, block 1035 is skipped. 
This type of "guessing" may be user enabled, or may be only 
attempted for forms that are similar to known forms. 

At block 1020, if the form was found in the user's 
transaction database, the process continued to block 1040. 

50 At block 1040, the process tests whether any data in the user 
profile has been changed since the transaction in the trans- 
action database was recorded. Transaction records are dated, 
as are changes to the user profile. A user profile may be 
changed by the user, for example, to change a credit card 

55 expiration date, number, or home address. If a user profile 
change of a relevant field is dated after the transaction record 
date, the process continues to block 1045, otherwise, the 
process continues directly to block 1050. 

At block 1045, the changed information is filled in from 

60 the user profile. In this way, the user only had to update his 
or her records once, in the profile, and that change is carried 
through the IIM. For one embodiment, this step may be 
skipped. For another embodiment, this step may be user 
enabled. 

65 At block 1050, the remaining form control identifiers in 
the form are filled with data from the transaction database. 
The process then continues to block 1055. 
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At block 1055, the filled-in form is displayed to the user, 
and the user is permitted to edit the data in the form. The 
user, for example, may not wish to provide certain data to a 
destination server. The user may chose to erase such data. 
Alternatively, the form may request data that is not found in 
the user's profile. The tiser may chose to fill in such data. 

At block 1060, the user submits the form to the destina- 
tion server. For one embodiment, the IIM stores the infor- 
mation submitted to the server in the user's transaction 
database. This is Ulustrated in FIG. 13 below. At block 1065, 
the process ends. For one embodiment, the user may option- 
ally select whether to use the user profile, transaction 
database, or both, and in what order, for form fill functions. 

FIG. 11 is a flowchart of one embodiment of the learning 
process in the database. At block 1110, a privileged user 
connects to the IIM. For one embodiment, this privileged 
user is an employee of the group maintaining the IIM. For 
another embodiment, this "user" is an artificial intelligence 
unit that is used to identify, forms, as will be described 
below. Such intelligent recognition programs are known in 
the art. 

At block 1120, the privileged user accesses a destination 
server page with a form through the IIM. At block 1130, the 
IIM displays a user interface for cataloguing the form. 

At block 1140, the user maps each form control to an 
element in the user profile object, the user profile is set up 
to contain a large number of possible data elements. Each 
form control should have a corresponding profile element. If 
no profile element is found for a form control, that form 
control may be tagged as "form specific." For one 
embodiment, muhiple elements in the user profile may be 
associated with a single form control, or vice versa. 

At block 1150, other information about the form is added. 
This information may include such information as the 
address of the form, whether the connection with the des- 
tination server that serves the form is a secure connection, 
whether the form is of a particular classification, etc. 

At block 1160, the user submits the information to the 
IIM. 

At block 1170, the IIM updates the form identification and 
form description in the form database to include the infor- 
mation added by the user. For one embodiment, the updating 
is a periodic batch updating. For one embodiment, a single 
central form database is maintained. In that instance, the 
lIM's updating may include sending the new form to other 
IIMs. Alternatively, each IIM may maintain its own separate 
form database. For yet another embodiment, an IIM may 
have a central form database, and a separate internal form 
database. This may be use^, for example, for an IIM 
implemented within a company which has the general form 
database for pages accessed outside the company, and a 
separate internal database for internal web page forms. 

At block 1180, the process ends. Of course, the privileged 
user may enter multiple entries, and may start the process 
again at block 1120. 

FIG. 12A is a flowchart of one embodiment of adding 
accounts. At block 1210, the user connects to the IIM 
through a client browser. At block 1220, the user accesses a 
destination server through the IIM. For one embodiment, the 
user accesses the account log-in page of the DS. This may 
be, for example, the account log-in page of the user's bank, 
of a portal, or of any other DS. 

At block 1230, the user requests to add the account to the 
user's account database. Each user may have an account 
database, which includes a list of accoimts the user can 
access with a single click. 
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At block 1235, the process determines whether the user 
has submitted login information to the account log-in page. 
If the user has not submitted the information, the process 
continues to block 1240, and the user is prompted to 

5 complete the log-in process. For one embodiment, if the 
account log-in process includes multiple pages, the user may 
indicate the end of the log-in process by pressing a certain 
key, or through other means. The process then continues to 
block 1245. If the user has submitted all of the log-in 

10 information, the process continues to block 1245 directly. 
At block 1245, the account entry is added to the user's 
account database. The account log-in information and data 
of account entry creation are recorded. For one embodiment, 
further information may be recorded. For yet another 

15 embodiment, only the user's log-in procedure is recorded. 
At block 1250, the account information is submitted to the 
DS for login. At block 1255, the process ends. 

FIG. 12B is a flowchart of one embodiment of accessing 
an account through an auto- log- in feature. At block 1260, 
the user connects to the IIM. At block 1265, the user 
accesses the account auto-log-in feamre using the IIM tiser 
interface. For one embodiment, this is done by the user 
pushing the account button. 

25 At block 1270, the user selects an account to log into. For 
one embodiment, the user may have multiple accounts. In 
that instance, the IIM displays the accounts that the user has. 
For another embodiment, if the user only has a single 
account, that accoimt is automatically selected when the user 

30 accesses the auto-log-in feature. 

At block 1275, the IIM retrieves login information from 
the user's account database. As discussed above, the user's 
previous account log-in is monitored and recorded. This 
information is retrieved at block 1275. 

35 At block-1280, the IIM sends the log-in information to the 
appropriate destination server to log-in the user. The account 
information includes the address of the DS. The IIM 
accesses the DS as a client, and sends the user's information. 

At block 1285, the IIM instruments the DS's response and 
sends it to the user's browser for display. As discussed 
above, the response is instrumented such that references of 
interest are routed through the UM. The user can now use the 
account, as usual. At block 1290, the process ends. 

FIG. 13 is a flowchart of one embodiment of the trans- 
action management functionality. At block 1310, the user 
connects to the IIM. 

At block 1320, the user transmits information in a form to 
the destination server. For one embodiment, the user first 

5Q accesses a destination server page including a fonn through 
the IIM. This form may be an order fonn, an e-mail form, or 
any other type of form; The user then fills in the form and 
submits it to the DS. For one embodiment, the user may use 
the form-fill method described above to fill-in the form. 

55 At block 1330, the process determines whether the user 
sent the user's e-mail address to the DS. The user may 
submit his or her e-mail address so the DS can send 
responses directly to the user's e-mail. For example, certain 
systems may send confirmation e-mails or alert notices to 

60 the user via e-mail. If the user submitted his or her e-mail 
address, the process continues to block 1340. Otherwise, the 
process continues directly to block 1350. 

At block 1340, the e-mail address submitted to the DS is 
altered. Specifically, the e-mail address is bifurcated, gen- 
es erated two e-mails. The first e-mail goes to the user's e-mail 
address, as entered. The second e-mail goes to the IIM. The 
second e-mail includes in its address the IIM and the 
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transaction tag that identifies the transaction number to connects to the IIM. For one embodiment, the homepage is 

which the e-mail belongs. This allows the IIM to handle the preset. For another embodiment, the user may not alter the 

e-mail. The process then returns to block 1350. homepage, and the homepage is customizable but includes 

At block 1350, the IIM records a transaction in the user's advertising. The process then continues to block 1530, and 
transaction database and associates the submitted informa- 5 ends. 

lion with the transaction. The transaction, for one FIG. 15B is a flowchart of one embodiment of using the 

embodiment, has a transaction number. bookmark functionality. At block 1535, the user connects to 

At block 1360, the IIM determines whether there is a the IIM. At block 1540, the user requests access to the user's 

response from the DS. If there is a response, the process bookmarks through the IIM user interface. For one 

continues to block 1370. Otherwise, the process continues embodiment, the user requests the bookmarks by pressing 

directly to block 1380. the "Tags" button on the user interface. 

At block 1370, the IIM records the response from the DS At block 1545, the IIM generates a bookmark list from the 

in the user's transaction database. For one embodiment, the user's bookmark database, and sends the list to the client 

destination server may respond to the user. This response is browser to display. For one embodiment, the bookmark list 

associated with the transaction record. In this way, the user is displayed in the destination server display area. For 

may review the transaction record, including the response. another embodiment, the bookmark list is displayed in a 

At block 1380, further information is recorded about the separate window, or a separate frame, 

transaction. For one embodiment, this information may At block 1550, the user selects a bookmark to access a 

include the date and time of the transaction, and other destination server page. 

information. At block 1555, the IIM fetches the page address corre- 

At block 1390, any notes, data, or e-mails received with sponding to the selected bookmark from the bookmark 

the transaction tag are attached to the transaction. This may database. The bookmark database includes the actual 

occur at any time, while the transaction is being recorded, or address of the bookmark. 

after that The user may attach any data to the transaction, 25 At block 1560, the destination server page is fetched by 

and the IIM may automatically attach any e-mails received the IIM. The data from the destination server is instrumented 

with the transaction tag. and is sent to the client browser for display. In this way, the 

At block 1395, the process ends. user can access bookmarks stored in the IIM's bookmark 

FIG. 14 illustrates one embodiment of the listing of database. The process then continues to block 1565, and 
transactions. The transaction list 1410 may be sorted by date, 30 ends. 

using a menu 1425. The transactions may also be sorted by FIG. 15C is a flowchart of one embodiment of using the 

type 1435. For one embodiment, alternative methods of history functionality. At block 1570, the user connects to the 

searching transactions may also be implemented. For IIM. 

example, a user may search the transaction records for At block 1575, the user requests access to the history list 
purchases from a certain destination server. 35 through the IIM user interface. The history list includes the 

Each transaction record may include one or more of the sites the user previously visited. For one embodiment, the 

following: date 1420, transaction type 1430, and description history list is maintained for only a period of time, such as 

1440 of the transaction. The record may further include the thirty days. For another embodiment, the history list is 

place 1450, the location from where the transaction was maintained indefinitely, and may be purged by the user, 

recorded. The user may add and edit additional notes 1460. At block 1580, the IIM generates a history list from the 

Furthermore, the user may also add attachments 1415 to the user's history database, and sends the history list to the client 

transaction record. For example, the user may attach e-mails, browser for display. For one embodiment, the history list is 

documents, video, or other types of data. For one displayed in the destination server display area. For another 

embodiment, e-mails may be redirected through the IIM and embodiment, the history list is displayed in a separate 

automatically attached to the transaction. ^jow, or a separate fi-ame. 

The vendor response 1470 is also recorded. The informa- At block 1582, the user selects a list entry to access the 

tion the user provided 1480 during the transaction is also destination server page. At block 1585, the IIM fetches the 

included in the transaction record. The transaction may page address from the history database. The page address is 

further include the information whether the transaction referenced through the IIM. 

belongs to one of the accounts 1490 in the user's account ^t block 1590, the IIM fetches the destination server 

database. The user is permitted to delete selected transaction p^ge, instruments the communication, and sends the data to 

records using a delete button 1465. ^Uent browser for display. At block 1595, the process 

FIG. 15A is a flowchart of one embodiment of selection ends. In this way, the IIM permits a user to access a variety 

of a home page. The user connects to the IIM at block 1505. of services through the IIM. 

At block 1510, the user accesses a destination server page FIGS. 16A-C show sample alterations of references from 

through the IIM. At block 1515, the process determines the destination server by the IIM. FIGS. 16A-C illustrate 

which option the user is selecting. changes to HTML, HTTP protocol, JavaScript, and Java. For 

If the user is selecting the add bookmark option, the one embodiment, this technique may be expanded to new 
process continues to block 1525. At block 1525, the address go languages and other types of interfaces. The data that is 

of the page is added to the user's bookmark database. This normally communicated directly between a Destination 

database is accessible to the user, to permit the user to access Server (DS) and client browser is altered by the IIM, as 

various web sites without typing the address of the site. The shown by FIGS, 16A-C, For one embodiment, some data 

process then continues to block 1530, and ends. may be transmitted directly between the DS and the client 

If the user selected the set home page option at block 65 browser, without passing through the IIM. 

1515, the address of the page is set as the user's homepage. For one embodiment, the IIM performs a subset of the 

The user's homepage is called up when the user initially message modifications required for redirection and down- 
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loads the client component to the client's browser, which 
performs the remaining subset of message modifications on 
the client machine. Together these two subsets of message 
modifications provide a complete solution for using an 
independent intermediary mechanism between a client and a 
server. 

The modification of HTTP communication messages for 
redirection occurs on both the IIM and the client browser 
using the client component. The points at which the message 
modifications occur are called "HTTP control points". 

FIGS. 16A-C illustrate examples of HTTP) control points 
that occur on the client browser and the IIM. For HTTP 
message documents, description of modification code covers 
the three programming languages that are most widely used 
today for HTTP communication: HTML, JavaScript and 
Java. For another embodiment, the IIM utility may be 
broadened to include HTTP control points in other program- 
ming languages used for HTTP message documents. For one 
embodiment, the protocol modified in the messages is 
defined by the HTTP specification standard. One skilled in 
the art would understand how to expand the technique 
described to different programming languages or message 
protocols. 

FIG. 17 is a table illustrating examples of making the IIM 
user interface frame persistent. The IIM prevents DS*s from 
overwriting the user interface of the IIM. This permits the 
user to access the IIM regardless of what DS he or she is 
accessing. 

FIG. 18 is a table illustrating examples of accessing 
cookies from the IIM. Generally, the destination server and 
destination server data on the client system access the cookie 
cache on the client's computer system. The IIM modifies the 
access mechanisms to access cookies from the IIMs cookie 
database. 

FIG. 19 is a table illustrating examples of preserving top 
frame or IIM frame integrity for DS. Objects are often hung 
from die top frame of the client browser. The IIM changes 
the references to the top frame to create or access these 
objects to references to the top firame of DSDA. In this way, 
the objects are appropriately handled. 

FIGS. 16-19 list some sample alterations resulting from 
the code instrumenting described above. Alternative meth- 
ods of altering the code may be used. One skilled in the art 
knows how to implement different changes. 

In the foregoing specification, the invention has been 
described with reference to specific exemplary embodiments 
thereof. It will, however, be evident that various modifica- 
tions and changes may be made thereto without departing 
from the broader spirit and scope of the invention as set forth 
in the appended claims. The specification and drawings are, 
accordingly, to be regarded in an illustrative rather than a 
restrictive sense. 

What is claimed is: 

1. A method of accessing data through an independent 
intermediary mechanism (IIM), the method comprising: 

displaying a frame including a user interface of the IIM, 
the frame framing a destination server display area 
(DSDA); 

retrieving destination server data (DS data) for display 
from a destination server; 

instrumenting the DS data prior to display such that future 
data retrieved from the destination server is displayed 
in the DSDA, without writing over the frame display- 
ing the user interface of the IIM. 

2. The method of claim 1, wherein the step of instrument- 
ing data prior to display comprises replacing a reference to 
a top frame or IIM frame with a reference to a top of the 
DSDA. 
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3. The method of claim 2, wherein said step of replacing 

comprises, 

in HTML, determining if a value of a Target attribute is 
"_top*\ and changing the value to represent a topmost 
5 area of the DSDA. 

4. The method of claim 2, wherein said step of replacing 
comprises, 

in Java, determining if a value of a Target attribute is 
"_top", and changing the value to represent a topmost 
10 area of the DSDA. 

5. The method of claim 2, wherein said step of replacing 
comprises, in JavaScript, replacing the reference to "top" 
with a reference to a topmost area of the DSDA. 

6. The method of claim 1, further comprising: 
altering requests for cookies such that cookies relevant to 

the destination server are accessed from the IIM. 

7. The method of claim 6, wherein cookies received from 
the destination server or created by the DS data are stored in 
a user's portion of the IIM. 

20 8. The method of claim 1, further comprising: 

determining if a user's portion of the IIM includes a 
cookie for the destination server, and serving the cookie 
to the destination server and to the DS data, if the user's 
portion includes the cookie. 
2^ 9. The method of claim 8, further comprising determining 
if a browser includes the cookie, and if the browser includes 
the cookie: 

serving the cookie to the destination server and the DS 
data; and 

saving the cookie in the user's portion of the IIM. 

10. The method of claim 1, wherein at least one reference 
in the DS data to other DS data is redirected through the IIM. 

11. The method of claim 10, wherein for predefined 
JavaScript, HTML and other code, the step of instrumenting 
is performed on a server side of the IIM, and wherein for 
dynamically generated code, the step of instrumenting is 
performed on a client side of the IIM. 

12. The method of claim 1, wherein the step of altering 
data prior to display comprises replacing the DS data 
references to a reference through the IIM. 

13. The method of claim 12, wherein only selected 
references are routed through the IIM. 

14. The method of claim 12, wherein said step of replac- 
ing comprises altering a language of the reference such that 
any parameter which when set causes a document to be 
fetched from the destination server causes the document to 
be fetched through the IIM. 

15. The method of claim 1, wherein links and references 
invoked by a user's selection are altered when the user 
selects the reference. 

16. An independent intermediary mechanism (IIM) com- 
prising: 

a core engine retrieving destination server data (DS data) 
for display from a destination server; 

a user interface fi-amework for maintaining a frame 
including the IIM user interface on a client browser as 
the client browser accesses different destination serv- 
ers. 

17. The IIM of claim 16, further comprising: 
a cookie database; 

a cookie modification engine that alters a request for a 
cookie from the destination server or the DS data, such 
that the cookie relevant to the destination server is 
65 accessed from the IIM cookie database; and 

the cookie modification engine further for maintaining 
and updating the cookie. 
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18. The IIM of claim 16, further comprising: 

a data modification engine for instrumenting the DS data 
such that future data retrieved from the destinatioQ 
server is retrieved through the IIM. 

19. A method of accessing data through an independent 5 
intermediary mechanism (IIM)» the method comprising: 

retrieving destination server data (DS data) for display 

from a destination server; 
instrumenting the DS data such that future data retrieved 

from the destination server is retrieved through the IIM. 

20. A method of accessing data through an independent 
intermediary mechanism (IIM), the method comprising: 

retrieving destination server data (DS data) for display 
from a destination server; 
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altering a request for a cookie from the destination server 
or the DS data, such that the cookie relevant to the 
destination server is accessed from the IIM; and 

storing and updating the cookie in-the IIM cookie data- 
base. 

21. A communications mechanism comprising: 
a first independent intermediary mechanism (IIM) dis- 
playing a frame including a user interface of the IIM, 
the frame framing a destination server display area 
(DSDA); 

the first IIM retrieving destination server data (DS data) 
for display from a destination server and instrumenting 
the DS data prior to, the first IIM further for providing 
services to the user. 

♦ * « * « 
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ABSTRACT 



A method and apparatus are provided for selectively authen- 
ticating and authorizing a client seeking access to one or 
more protected computer systems over a network. A request 
of a client to access one of the computer systems is received. 
A proxy security server is requested to authenticate the client 
using information identifying the client. An authorization of 
the client from the proxy security server is received, based 
on authentication results received from a remote security 
server that is coupled to the proxy security server. In 
response, access rights of the client are established, based on 
one or more access information records received from 
remote security server through the proxy security server. As 
a result, one or more legacy security servers may be easily 
integrated into an application access system without com- 
plicated modifications to the application access system. 

29 Claims, 8 Drawing Sheets 
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INTEGRATING HETEROGENEOUS procedure. Even if two security systems use the same 

AUTHENTICATION AND AUTHORIZATION authentication procedure, such as user id/password 

MECHANISMS INTO AN APPLICATION authentication, a user may use one user id and password pair 

ACCESS CONTROL SYSTEM on one system, and another user id and password pair on 

5 another system. Obviously, tracking different user ids and 
passwords can be very burdensome to a user, 

FIELD OF THE INVENTION Another disadvantage of the foregoing approach is duph- 

The present invention relates to security systems in com- f management processes. To provide user aa:ess to 

puter systems, and in particular, integration of hetercge- ,„ °^ applications, an administrator mi^t repeatedly add 

neous security systems into an application access control '° J" "'^'^ secunty system in use. The redundancy of 

svstem processes, combmed with rapid growth in the number 

^ of users, can make the cost of deploying, managing and 

BACKGROUND OF THE INVENTION supporting a system unacoeptably high. 

Another disadvantage stems from the use of a common 
Computer networks have become ubiquitous in business, is ^^^^ interface for accessing applications over a network. The 
industry, and education. These networks typically have one user interface is configured to interact with each security 
or more resources, such as applications, that provide various mechanism that may be accessed through the common user 
computing functions. Development of the globally interface. Thus, adding a new security mechanism for a new 
accessible, packet-switched network known as the Internet or existing application may require reprogramraing, 
has enabled network resources to become available world- 20 recompilation, and reinstallation of the common user inter- 
wide. Hj^ertext protocols that implement the World Wide face, 

Web have evolved, ("The Web"), enabling networks to serve p;,^ ^^^^pj^^ ^^^-^^ mechanisms such as retinal 

as a platform for global electronic commerce and the easy scanners are becoming available. However, integrating such 

exchange of mformation between busmesses and their niechanisms is difficult. The required effort may increase 

customers, suppliers and partners. 25 ^^^^ ^^j^y^ implement new applications and security 

Businesses are rushing to make their applications avail- mechanisms to undesirably high levels, 

able over networks, including the Web, and just as quickly g^sed on the foregoing, it is clearly desirable to provide 

stumbling into several roadblocks. For example, some infor- 3 mechanism to govern access to one or more information 

malion is valuable and sensitive, and needs to be made resources in which selective access is given to particular 

available only to selected users. Thus, there is a need to ^ mechanism that is equaUy adaptable to an internal 

provide selective access to network resources and informa- network environment and to an external network environ- 

tion over the Web. menX and which takes advantage of existing security 

This need exists in the context of internal Web networks mechanisms, and a mechanism that is easy to re-configure as 

that are available to employees of an organization, called new user applications and authentication techniques become 

Intranets, as well as Web networks and resources that are available, 
available to external customers, suppliers and partners of the 

organization, called extranets. Extranet users may require SUMMARY OF THE INVENTION 

access to a large number of applications, for example, jhe foregoing needs and objects, and other needs and 

product catalogs, customer databases, or inventory systems. objects that will become apparent from the following 

There may be millions of potential users, the number of description, are achieved by the present invention, which 

which grows dramatically as an organization grows. comprises, in one aspect, an access control system. The 

One approach to some of the foregoing problems and access control system includes a server which provides 

needs is the application approach. Under the application authentication and authorization services. The server uses 

approach, a security mechanism is provided for each appli- 45 the authentication and authorization services from a set of 

cation program. Often, the security mechanism provided for remote servers, which may be servers that provide the 

an application is the application's own native security sys- authentication services from legacy access control systems, 

tern. When a user connects to an application through a or specialized access control systems such as authentication 

network, the security mechanism for the application is services based on retinal scans. 

invoked. For example, when connecting to an accounting jq jhe services of the remote servers may be accessed 
application, the accounting application invokes its security through proxy servers. The proxy server serves as an inter- 
mechanism. The security mechanism obtains a user id and face between the server and the other remote servers, and 
password fi-om the user, and then authenticates the user. provides an API through which the services of the remote 
Authentication refers to the process of using information to servers may be accessed. The proxy servers may be instan- 
idenlify a user ("authentication input") and verifying that the 55 tiations of a subclass of a base class. The base class defines 
user is what the information purports the user to be. methods for the API. Due to the power and simphcity of the 
Examples of authentication input include user id and pass- inheritance feature of object oriented technology, developers 
word received from a user, or a digital certificate. may develop subclasses which inherit the metiiods of the 

An advantage of the application approach is that it may base class. A software developer need only implement 

use security mechanisms that already exist. Use of existing go methods needed to interface with a particular remote server, 

security systems avoids reprogramming applications to use A remote server may provide authentication services, 

another security system and reconfiguring the other security authorization services, and the abitity to edit information 

system, by, for example, re-entering the user id and pass- stored on the remote servers regarding users. The authori- 

words of existing users. zations received by a server from the remote server may be 

A disadvantage of the application approach is that it 65 translated into a form of authorizations used by the server, 

results in a heterogeneous set of security mechanisms, each The translated authorizations may be migrated to the server, 

of which may present the user with a different authentication and stored in persistent storage for later use by the server. 
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BRIEF DESCRIPTION OF THE DRAWINGS work 102 is a compatible information communication 

^ . • I, . . J u c 1 network, such as the Internet. In alternate embodiments, the 

Tlie present mvention is illustrated by way of example, ^^^^ ^ ^j.^^^ ^jj^^^ workstation of any 

and not by way of lunuation in the figures of the accom- convenient type, and the network 102 is a data communi- 

panymg drawings and m which like reference numerals refer ^ nation network that can transfer information between the 

to similar elements and m which: cUent and a server that is also coupled to the networic. 

FIG. 1 is a block diagram depicting an access control Authentication and Authorization Module 114 manages 

system coupled to a system protected by the access control authentication and authorization services in Information 

system; Access System 100. To provide authentication and authori- 

FIG. 2 is a block diagram depicting an access control 10 Jfjo" ^emces, Authemication and Authorization Module 

system in greater detail than FIG. 1; V .r?- ^ a ^° \f "^^^^ '^^"^l^H f^^.TT^S^^ 

^ ,j, . , Authentication and Authorization Module 114 or uses 

nG.3A IS a block diagram of method that may be used authentication and authorization services provided by 

to implement an integration of secunty systems m an Remote Security Servers 140. The authentication and autho- 

application access system; rization services provided by Remote Security Server 140 

FIG. 3B is a block diagram of additional methods; may be accessed through a Proxy Security Server 130. A 

HG. 4A is a flow diagram of a method of integrating P^o^y Security Server 130 serves as an interface between 

security systems into an application access system; Authentication and Authorization Module 114 and a Remote 

^^, v^^ 5r ^'^^'^"^ ^'"^^ ^ St^'servers 130 provide an application pro- 

method ot MU. 4A; 20 grammer interface ("API"). An API is a symbolic interface 

FIG. 4C is a flow diagram of further steps in the method that defines inputs and outputs to a set of computer program 

of FIG. 4A; routines through which services provided by a server may be 

FIG. 5 is a block diagram depicting a computer system accessed by clients of the server. The API provided by Proxy 

upon which an embodiment of the present invention may be Security Servers 130 allows Authentication and Authoriza- 

implemented. 25 Module 114 to access services provided by Remote 

Security Servers 140. To assist Remote Security Servers 140 

DETAILED DESCRIPTION OF THE in servicing the requests of Information Access System 100, 

PREFERRED EMBODIMENT Authentication and Authorization Module 114 also provides 

A method and apparatus for integrating heterogeneous ^ ^! ^ ^^f^ ^ecu^J^y l^^'^ l^^- ^^"^ 

, . r • • * 1- services are also accessed through the API. 

au henucauon and authorizaaon mechamsms into an appli- 30 ^^^^ ^^^^^^ g^^. ^^^^^ ^ ^^^^^^ 

cation access control system B described. In the foUowing ^^gj^^ ^^^^ manage information 

descnption, for the purposes of explanation, numerous spe- 3^0^ access rights of one or more applications residing on 

cific details are set forth m order to provide a thorough protected Servers 104. Access rights refer generally to 

understanding of the present mvention. It will be apparent, actions that may be performed on behalf of a given user, 

however, to one skilled in the art that the present invention 35 including, for example, access to read or write data from a 

may be practiced without these specific details. In other Resource. A Remote Security Server 140 may be, for 

instances, well-known structures and devices are shown in example, a legacy security service used by an accounting 

block diagram form in order to avoid unnecessarily obscur- application that resides on a Protected Server 104, which 

ing the present invention. may be running under the Windows NT''** operating system. 

Operational Context 40 llie legacy security service is the security service provided 

FIG, 1 is a block diagram depicting elements of an by Windows NT. Authentication and Authorization Module 

information access system 100 according to a preferred 114may access the security service of Windows NT through 

embodiment. Generally, an Information Access System 100 a Proxy Security Server 130. This ability enables Informa* 

comprises a plurality of components including an Access tion Access System 100 to manage access to the accounting 

Server 106, Registry Server 108, and Proxy Security Servers 4S application through information and services that already 

130, and Remote Security Servers 140. The foregoing com- exist on other security systems, preserving time, effort, and 

ponents cooperate to control access to resources stored on money already invested in those systems. 

one or more Protected Servers 104. Each component com- Access Roles 

prises one or more modules. There may be any number of The Information Access System 100 enables administra- 

Protected Servers 104. Users are individuals who have a 50 tors to implement access rules by defining roles (Access 

relationship with an organization and play various roles, and Roles) that users perform when working for an organization 

are registered in the system 100. Users may be members of or conducting business with an enterprise. An Access Role 

an organization, or may be customers, suppliers, or business may reflect a relationship of a user to the organization 

partners of the organization. Administrators control the (employee, customer, distributor, supplier), their department 

system. A server is a executable module that resides on at 55 within an organization (sales, marketing, engineering) or 

least one computer and which provides services to clients any other afiBliation or function (member of quality task 

requesting those services. force, hotline staff member) that defines their information 

In one embodiment. Protected Servers 104, Access Server needs, and thus their access rights or privileges. Examples of 

106, and Registry Server 108 are configured as disclosed in Roles include Employee, Customer, Distributor, Supplier, 

co-pending application Ser. No. 09/113,609 filed Jul. 10, 60 Sales, Marketing, Engineering, and Hotline Staff. 

1998, the entire disclosure of which is hereby incorporated Access Roles are defined by information identifying a 

by reference as if fully set forth herein. name of a role and by a functional group in which the role 

A browser 103 is coupled by a communication link to a resides. A functional group is often a department in which 

network 102. The block shown for browser 103 represents a similar functions exist. Examples of functional groups are 

terminal, workstation computer, or an equivalent that 6S Marketing, Sales, Engineering, Human Resources, and 

executes a standard Web browser program or an equivalent. Operations. Access Roles are also associated with a User 

such as Netscape Communicator or Internet Explorer. Net- IVp^- 
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Access Roles determine what resources a User can access. tion and Authorization Module 114 returns information that 

Further, each Access Role may aUow access to a subset of specifies whether the user is authenticated, and the access 

information that is available in resources. For example, a roles for the user. 

User who is an Employee in the Marketing department could The Authentication and Authorization Module 114 

access Price List and New IVoducts Resources. Thus, Infor- 5 authenticates the user in one or more ways. The Aulhenti- 

mation Access System 100 enables the creation of resource cation and Authorization Module 114 may authenticate a 

profiles by assigning roles to resources, and by assigning user by verifying the password with the Registry Server 108. 

roles to users to generate access rights. Information Access Alternatively, the Authentication and Authorization Module 

System 100 automatically links a user to the resources 114 may use authentication services of one of the Remote 

profiles that have been assigned the same roles, so that lO Security Services 140 to authenticate the user, 

deployment of new resources may occur rapidly. The Registry Server 108 manages a registry repository 

Information Access System 100 may manage such roles 109, which may be structured as a database. The registry 
using the methods and mechanisms disclosed in co-pending repository contains information about how to authenticate 
application Ser. No. 09/248,764, filed Feb. 12, 1999, the users and what authorizations a user has, including a map- 
entire disclosure of which is hereby incorporated by refer- is ping of a particular user to access roles. Information about 
ence as if fully set forth herein. how to authenticate a particular user is referred to as an 
User Login authentication profile, and may include data indicating a 

The Information Access System 100 also enables Users to user id, password, and which Proxy Security Servers 130 to 

log-in to the system once, and thereafter access one or more use to authenticate a user. An authorization is a privilege to 

resources on a network during an authenticated session. 20 perform a particular action with respect to a set of resources 

Users may, for example, log in either with a digital certifi- on a computer system. For example, an authorization may 

cate or by opening a login page URL with a web browser and define access to a particular Web page or a set of directories, 

entering a name and password. In the past, users have had to For each user it authenticates, the Authentication and 

log in individually to each application that they are autho- Authorization Module 114 generates data representing the 

rized to use. In the preferred embodiment, users always 25 authorizations of the user in the form of access roles. The 

access the same login page regardless of the number of Authentication and Authorization Module 114 generates the 

resources to which they need access. Thus, the system access roles using authorization information recorded by 

provides a mechanism of single secure log-in to resources Registry Server 108, or authorization information obtained 

available on a network. from Remote Security Service 140 through a Proxy Security 

When a user attempts log in. Information Access System 30 Server 130. It then encrypts data representing the access 

100 establishes a session. Specifically, a unique session roles and sends the encrypted data in a cookie to the user's 

number is generated, and port and connection information browser. A "cookie" is a packet of data sent to web browsers, 

("session information") is stored in association with the Each cookie is saved by browser 103 until the cookie 

session number. The combination of a session number and expires. A returned cookie is required for access to resources 

session information is referred to as a session. Session 35 protected by Information Access System 100. 

information includes information that identifies a user, and A Session Manager 112 manages sessions throughout 

that indicates whether the user has been authenticated. A Information Access System 100. Session Manager 112 

session associated with a user that has been authenticated is establishes new sessions upon request by various compo- 

referred to as an authenticated session until the authenticated nents of Information Access System 100, including, for 

session expires. An authenticated session may, for example, 40 example, Access Server 106 when Access Server 106 is 

expire after the elapse of threshold period of time. Until the logging in a user. Session Manager 112 also expires sessions 

authenticated session expires, the user associated with the according to various criteria and techniques, 

authenticated session may access one or more resources Logging Service 116 receives information about the 

protected by the Information Access System 100. actions taken by various modules of Information Access 

If the Login attempt is successful, that is, the user has 45 System 100 and records actions as events in one or more 

been authenticated and is authorized to access resources logs. For example, when Session Manager 112 expires an 

protected by Information Access System 100, the Infonna- authenticated session, Session Manager 112 transmits a 

tion Access System 100 presents the user with a personal- message to record the expiration of the authenticated ses- 

ized menu. The personalized menu assists the User in sion. 

identifying and selecting a resource to access. In one 50 The Topology Mechanism 118 tracks various components 

embodiment, a personalized menu is an HTML page con- of Information Access System 100 when the components 

taining a list of authorized resources. The personalized menu starts up. In particular, Topology Mechanism 118 receives 

displays only resources to which the User has access. The messages from a particular component when it starts up, 

user can then select and access a Resource. and, in respoase, may transmit messages to other compo- 

Session information may be structured and managed 55 nents to inform them that the particular component has 

using the methods and mechanisms disclosed in co-pending started. 

application Ser. No. 09/363,315, filed Jul. 28, 1999, the Integration Tools 115 are selectively executed on Infor- 

entire disclosure of which is hereby incorporated by refer- mation Access System 100 and function to customize the 

ence as if fully set forth herein. particular configuration of the foregoing components. For 

Integrating Authentication Mechanisms 60 example. Integration Tools 115 are used to customize the 

FIG. 2 shows Information Access System 100 in greater form or content of screen displays presented by browser 103 

detail. Access Server 106 stores a log-in page, and is coupled for user login and logout, or to enforce password selection 

to the Authentication and Authorization Module 114. The rules, or to program and develop Proxy Security Servers 

Access Server 106 may receive authentication input regard- 130. Integration Tools 115 include Proxy Security Server 

ing a particular user for a particular session and transmit it 65 Base Class 117, which are later described, 

to the Authentication and Authorization Module 114, which Proxy Configuration Data 113 is data that specifies the 

uses the information to authenticate a user. The Authentica- configuration of each of Proxy Security Servers 130. Proxy 
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Configuration Data 113 specifies, for example, whether a Services Provided by Proxy Security Servers Through the 

particular Proxy Security Server 130 provides authorization Common API 

services. Proxy Configuration Data 113 shall later be A Proxy Security Server 130 makes available services 

described in greater detail. provided by Remote Security Servers 140 to Information 

In one embodiment. Information Access System 100 is 5 Access System 100. These services are accessed by invoking 

stored on and executed by one physical server or computer. a method of the API, and in particular, may be accessed by 

In alternate embodiments, one or more components are invoking methods of Proxy Security Servers 130, The meth- 

installed on separate computers. ods may be implemented in the Proxy Security Server 

Starting Up the Authentication and Authorization Module Subclasses 200, as shown in FIG. 3 A, although for some of 

and Proxy Security Servers 30 these methods a default behavior is implemented in the base 

In an embodiment, the Session Manager 112, Logging class. A description of the methods that may be 

Service 116, and Topology Mechanism 118 start up before implemented, and the functionality they provide as services. 

Authentication and Authorization Module 114 and any of follows. Additional details about these methods and their 

Proxy Security Servers 130. Relative to each other, a Proxy functionality, and about additional methods and 

Security Server 130 and the Authentication and Authoriza- is functionality, may be found in Appendix I. 

tion Module 114 may start-up in any order. AUTHENTICATION: A Proxy Security Server Base 

When the Authentication and Authorization Module 114 Class 117 defines at least one method that may be invoked 

starts up, it reads Proxy Configuration Data 113 and stores to authenticate a user. The authentication method 202 is 

data representing the Proxy Configuration Data 113 in implemented in a Proxy Security Server Subclass. See, for 

memory. Authentication and Authorization Module 114 then 20 example, pam_sm_authenticate in Appendix I. Generally, 

checks-in with the Topology Mechanism 118. If any of the implementation for this method is specific to a particular 

Proxy Security Servers 130 have previously started up and Remote Security Server 140. Authentication and Authoriza- 

checked-in with Topology Mechanism 118, then Topology tion Module 114 passes a session identifier and authentica- 

Mechanism 118 transmits a message to Authentication and tion input, such as a user id and password, digital signature. 

Authorization Module 114 indicating the availability of the 25 or biometric data, for example, a thumbprint image. The 

already running Proxy Security Servers 130. method is executed to authenticate the user associated with 

When a Proxy Security Server 130 starts up, it checks-in the session, in accordance with its then-current implemen- 

with Topology Mechanism 118. If Authentication and tation. The architecture and configuration of elements dis- 

Authorization Module 114 is already running, then Topology closed herein, in combination with the power and versatility 

Mechanism 118 transmits a message indicating the avail- 30 of object oriented languages that may be exploited to 

ability of the Proxy Security Server 130 that has just checked develop subclasses results in a set of Proxy Security Servers 

in. 130 that interface to a wide range of Remote Security 

Proxy Security Service Framework Servers 140. 

A Proxy Security Server 130 allows Authentication and REMOTE AUTHORIZATION: Proxy Security Server 

Authorization Module 114 to access any Remote Security 35 Base Class 117 may define at least one method that allows 

Servers 140 through a common API. The API enables Authentication and Authorization Module 114 to modify 

Authentication and Authorization Module 114 to interface authorizations on a Remote Security Server 140. The remote 

with any Remote Security Servers 140 in a common manner. authorization method 204 is implemented in a Proxy Secu- 

The Authentication and Authorization Module 114 and rity Server Subclass. See, for example, para_chauthtok 

Proxy Security Servers 130 may be compliant with Common 40 (String pamh), in Appendix I. The ability to modify autho- 

Object Request Broker Architecture (CORBA) communi- rizations on a Remote Security Server 140 is referred to as 

eating to each other using the framework defined by remote authorizations. A developer provides the implemen- 

CORBA. Proxy Security Servers 130 may be Java objects tation for the method. When Authentication and Authoriza- 

that are instantiations of Java classes. tion Module 114 invokes the method, it passes in a session 

Proxy Security Server Base Class 117 is an abstract class 45 identifier, 

from which Proxy Security Server Subclasses inherit meth- R EMOTE PROFILING : Pr oxy Security Server Base 

ods and data. A Proxy Sectu-ity Server Subclass, represented Class I L'^^^gBSs'ai least one method that provides the. 

in FIG. 2 by Proxy Security Servers 130, is a class from a bility to mooity a user profile on a Remote Security Server 

which a Proxy Security Server 130 may be instantiated. The l<w. Auser pronie is data describmg demograpnic informa - 

Proxy Security Server Base Class 117 defines methods of the 50 t ion about a user, for example, the user's address, full nam e. 

API. Some of the methods are implemented in the base class. and marital stat us. The method remote profiling 206 is 

Other methods are implemented in a subclass of the base i mplemented m a Pr ^?fy Sp.mi ptv Seyver Subclass. Se e, for 

class. "ex ample, pam chauthtok. in Appendix I. This ability to 

A Proxy Security Server 130 may implemented as multi- a lter a user profile on a Remote SecurUy Ser ver 140 

threaded CORBA server that interacts with the Authentica- 55 r eferred to as remote protilmg. A developer provides the 

tion and Authorization Module 114 and a Remote Security implementation tor t!ie method. When Authentication and 

Servers 140. The Proxy Security Servers Base Class 117 Authorization Module 114 invokes the method, it passes in 

supplies the implementations to support CORBA, multi- the session identifier. 

threading, and other aspects of a Proxy Security Server 130. COMMUNICATING AVAILABLE FUNCTIONALITY: 

Due to the power and simplicity of inheritance in object 60 Not all Proxy Security Servers 130 provide the same set of 

oriented development enviroiunent, a developer of a par- services. For example, a Proxy Security Server 130 may 

ticular Proxy Security Server subclass does not have to provide authentication and remote profiling, but not remote 

address CORBA or the multi-threaded aspects of a Proxy authorization. When a Proxy Security Server 130 starts up. 

Security Server subclass. Adeveloper need only extend from Authentication and Authorization Module 114 needs to 

the Proxy Security Server Base Class 117 to implement a 65 know what services a particular Proxy Security Server 130 

limited set of methods needed for a particular Remote provides. For this purpose, a Proxy Security Server Base 

Security Server 140. Class 117 provides at least one communication method. The 
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communication method 208 is implemented in a Proxy tion Access System 100 then transmits a message to a Proxy 

Security Server Subclass. See, for example. Security Server 130 that corresponds to the selected Proxy 

getImplementedFunctions( ) in Appendix 1. Security Server Name. In an embodiment, the message is 

Functionality Provided by Authentication and Authorization transmitted by invoking the pam_auth method of the Proxy 

Module to Proxy Security Servers 5 Security Server 130. 

To provide services to Authentication and Authorization The Proxy Server 130 then transmits a message indicating 

Module 114, a Proxy Security Server 130 may need to obtain that the user is authenticated to Authentication and Autho- 

information through Authentication and Authorization Mod- rization Module 114. In response, Authentication and Autho- 

ule 114, or request other services from Authentication and rization Module 114 registers the user id, storing in Registry 

Authorization Module 114. For example, a Remote Security lO Server 108 data specifying the user id and Proxy Security 

Server 140 may need to query a user to get data for changing Server Name. The user may later add or delete Proxy 

a user profile. Such services are accessed by invoking a Security Server Names, or other information in the user's 

method of the API defined in Proxy Security Server Base authentication profile. 

Class 117, A description of these services follows and FIG. Dynamic Authorization Mapping 

3B depicts the strucUire of the methods. Additional detaUs 15 Qnce a registered user is authenticated, the authorizations 

about these services and their functionality, and about addi- the user are determined. Typically, a user is associated 

tional services and methods, may be found in Appendix II. ^th a default set of authorizations. In addition, a system 

INTERFACING WITH A HUMAN USER: Proxy Secu- administrator may have assigned access roles to a particular 

rity Server Base Class 117 defines at least one method that ^hen a user logs into Information Access System 100, 

be mvoked to communicate with a human user. Such meth- 20 the Authentication and Authorization Module 114 gets from 

ods are refened herem to as conversation methods. See Registry Server 108 the access roles assigned to the user. In 

pam_conv m Appendix II. For example, to change a user addition, the Authentication and Authorization Module 114 

profile, a method that implements remote profiling may authorizations from any Proxy Security Server 130 

invoke a conversation method 210 to obtain inputs from the specified in the user's authentication profile, 

user that are used to update the user profile. Input parameters 25 ^h, authorizations obtained from Proxy Security Server 

passed to the conversation method may specify whether user ^^^^ ^^j^^^ ^^^^ 

input should be obtained using a text box, a label for the text converted to Access Roles in a process referred to as 

box, and whether user mput is echoed as it is entered, or a Authorization Mapping. In a dynamic authoriza- 

list of selections to be displayed in a hst box presented to the ^j^^ mapping, authorizations provided by Proxy Security 

human user. „ o • Servers 130 are converted to Access Roles based on a 

ENVIRONMEOT INFORMATION: Proxy Secunty ^ ^ ^ ^^^^^^ ^ p configuration 

Server Base Class 117 defines at least one method that may ^ata 113, and shall be described in greater detail. The 

be mvoked to obtain mformation about a user or the oper- ^^^^^ j^^j^ generated by the conversion are merged with 

ating environment For example, a method may be mvoked ^^^^ ^^^^^ yj^^ ^ S^^^^ ^^8 for the 

to obtain the user id and password associated with a session, 35 

or the network address of the device from which the user is ^ n * o •* o 

. . . ^ ^. . ^ ^ Migratmg Authonzations from Remote Secunty Servers 

attempting to log in. These methods may comprise a Get , ^ • ^ ^^r. , 

Environment method 212, Get Environment List method , Information Access System 100 may used to replace a 

214, Get Configuration method 216. and Get User Method «g="=y ^'^"'V ^y^'«">- m configurmg a 

218. See. para_g6tenv, pam_gelenvlist, pam_get_ 40 legacy security system with authentication and authorization 

configuration, pam_get_user. for example, in Appendix II. information may be preserved by impleraenlmg a Proxy 

Registration and Self Registration Secunty Senders 130 for the legacy secunty system 

Registration refers to a process of receiving data that « """y desired to eventually discontmue use of 

identifies a user and specifies an authentication profile for '^^ ^^^^^ ^yf"' ""fonnation on the legacy ^cunty 

the user. A user may be registered in Information Access 45 ^y^'*'^ "^"^^ ^ transferred to Information Access System 
System 100 in a variety ways. For example, a system 

administrator may use an administrative user interface pro- technique descnbed herein for efiBciendy transferring 

vided by Information Access System 100 for receiving data information is referred to Dynamic Migration. Dynamic 

used to register users from a system administrator. In Migration is the process of permanently assigning Access 

particular, Information Access System 100 receives input 50 ^""^^^ generated by converting information from a Remote 

that specifies a user id, which Information Access System Security Server 140. These converted access roles are sub- 

100 stores in Register Server 108. In addition. Information sequently associated with the user whenever the user logs in. 

Access System 100 receives data from a system adminis- Dynamic Migration may be performed when a user self 

trator specifying an authentication profile. The aulhentica- registers. Data m Proxy Configuration Data 113 specifies 

tion profile may include data specifying a Proxy Security 55 whether Dynamic Migration is performed for a Proxy Secu- 

Server Name that corresponds to a Proxy Security Server Server 130, that is, whether Dynamic Migration is 

130 used to authenticate the user. performed for a user who self registers and selects the Proxy 

Self-Registration refers to a process in which a user Security Server 130. 

registers itself, by supplying to the Information Access Configuration Data 

System 100 data that specifies an authentication profile. For 60 Configuration Data U3 is organized as one or more 

example, when a user first logs into to Information Access blocks of data, each of which is associated with a Proxy 

System 100, Access Server 106 presents a login page to the Security Servers 130. Each block contains entries that 

user. The login page includes a text box for the user to enter specify an operational aspect of a Proxy Security Server 130. 

a user id and a password, and a list box listing Proxy Each entry contains a string specifying a parameter name. 

Security Server Names as selections. The user enters the 65 followed by a character, followed by string specifying a 

strings "John Doe" as the user id and "DoeSUring" as the parameter value. An example of Configuiration File 15 

password, and picks a selection from the list box. Informa- follows. 
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[UserPasswordPam] 

nameoUserPasswordPam 

desc«Use rid/Password 

usrtag«Uscrid 

pwdlag-Password 

env= 

translateafalse 

selfreg^false 

aulhsourcename=UserPassword 

CODfig= 

getAccessRoot:c:\enCbmiiierce\getAccess||debug:false 
[CertPam] 
name»CeilPam 
desc=Certificate 
usrtag- 
pwdtag= 

env-CLIENT.CERIllCOOKIErCERTCOOKIE* 

traaslate»false 

selfieg>false 

authsourcename-Certificate 
config" 

getAccessRcx)t:c:\eDG3mmerce\getAccess||debug:false 

A block begins with a tag, which may be a bracketed 
string, that specifies a Proxy Security Server Name. The 
example above has two blocks. The first block begins with 
the tag '[UserPasswordPam]'. 

The first entry in the first block is the name value pair 
'name=UserPassword', and it specifies a Proxy Security 
Server Name, 'name' is the parameter name, and 'UserPass- 
word' is the Proxy Security Server Name. 

The Proxy Security Server Name is used to associate a 
Proxy Security Server 130 with a block. A Proxy Security 
Server 130 is associated with a Proxy Security Server Name 
when the Proxy Security Servers 130 is started, by, for 
example, specifying the Proxy Security Server Name as 
input argument value in the command used to invoke the 
proxy server. A Proxy Security Server 130 associated with a 
Proxy Security Server Name is herein referred to as the 
named Proxy Security Server 130. 

The parameter 'desc' specifies a description that is dis- 
played to the user to refer to the named Proxy Security 
Servers 130. 

Parameter 'usrtag* is the entry for the label displayed next 
to a text box used to receive user input specifying a user id. 

Parameter 'pwdtag' is the entry for the label displayed 
next to a text box used to receive user input specifying a 
password. 

Parameter *env' is used to specify an environmental 
variable that is caught. The block beginning with the tag 
[CertPam] indicates certification parameters and shows a use 
of the parameter 'env' . In this case, the environment variable 
could be called CLIENT_CERT, or can be sent in the form 
of cookies. 

The parameter 'selfireg" is used to specify whether a user 
may self register by selecting the named Proxy Security 
Server 130. 

The parameter 'translate' specifies whether dynamic map- 
ping is performed for the authorizations supplied by the 
named Proxy Security Server 130. 

The 'config' entry depends on the Proxy Security Servers 
130 itself. For example, a Proxy Security Servers 130 used 
to interface to a Remote Security Servers 140 that uses 
Windows NT Domain Authentication requires the number of 
domains to authenticate as well as the name of each of the 
domain. 
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Specifying a Mapping in the Configuration Data 

To perform dynamic authorization mapping, a mapping is 
specified in the block associated with a Proxy Security 
Server 130. The example entry illustrates a mapping for a 
5 Proxy Security Server 130 that interfaces with a Remote 
Security Server 140 that uses Windows NT Domain Authen- 
tication. 

[NTDomainPam] 

nameBNTDomainPam 

desc=NT Domain Authentication 

usrtag«Userid 

pwdtag» 

env= 
IS translate»true 

selfreg=true 

authsourcename=N IDomain 
config»numberOfDomains«l||domainl:Marketing 

2Q usertype-undef 

Domain Users»emplye 
Domain Admins»excacc.spradm 
The example Proxy Configuration Data 113 above speci- 
fies to Authentication and Authorization Module 114 that a 

25 Proxy Security Server 130 associated with the Proxy Secu- 
rity Server Name NTDOMAIN can perform self-registration 
and dynamic authorization mapping. If the authorizations 
redirned by the named Proxy Security Server 130 include 
the 'Domain Users' group, the user type will be translated to 

30 'emplye'. Likewise, if the returned authorizations include 
'Domain Admins', then the user has the administrative role 
referred to as 'excacc.spradm'. 
Example Method of Operation 
FIG. 4 A is a flow diagram of an exemplary method of 

35 operation of the system of FIG. 2. The method of FIG. 4A 
may be implemented in one or more computer programs, 
processes, data structures, or related elements that form 
Authentication and Authorization Module 114. 

In block 400, a request to access a protected server is 

40 received from a client. For example, Browser 103 as shown 
in FIG. 1 contacts Access Server 106 and requests an 
electronic document of one of the Protected Servers 104. 
Access Server 106 forwards the request to Authentication 
and Authorization Module 114. 

45 In block 402, a proxy security server is requested to 
authenticate the client using information that identifies the 
client. For example. Authentication and Authorization Mod- 
ule 114 uses authentication method 202 to request one of the 
proxy security servers 130 to authenticate the client. In the 

50 course of executing the authentication step, the proxy secu- 
rity server may use one of the remote security services 140 
to conduct authentication. 

If the authentication request is unsuccessful, then the 
access server returns a message to the cHent indicating that 

55 access is refused. These steps are omitted from FIG. 4A for 
clarity. If the authentication is successful, then in block 404, 
authorization is received from the proxy security server 
based on authentication results that are received from a 
remote security service that is associated with the proxy 

60 security server. 

In block 406, access rights for use with an apphcation 
access system and associated with the client are established. 
The process of FIG. 4C may be used. 

Optional processes may be carried out after block 406 or 

65 at any other appropriate time in the process, as indicated by 
block 408. FIG. 4B is a block diagram of optional processes 
408 that may be carried out. The optional processes 408 may 
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include one or more of remote authorizations 410, remote of the invention, an access control system is provided by 

profiling 412, or communications such as receiving infor- computer system 500 in response to processor 504 executing 

malioD on available proxy services, as indicated by block one or more sequences of one or more instructions contained 

414. Optional processes 408 may also include registration in main memory 506. Such instructions may be read into 

416 or self registration 418. These processes may be carried 5 main memory 506 from another computer-readable medium, 

out using the mechanisms described above with respect to such as storage device 510. Execution of the sequences of 

FIG. 2, FIG. 3A, and FIG. 3B. instructions contained in main memory 506 causes processor 

FIG. 4C is a flow diagram of further steps that may be 504 to perform the process steps described herein. In alter- 

used to carry out the process of block 406. native embodiments, hard-wired circuitry may be used in 

In block 420, authorizations associated with the current 30 place of or in combination with software instructions to 

client are received form the proxy security server. In block implement the invention. Thus, embodiments of the inven- 

422, a mapping of authorizations to access roles is obtained. tion are not limited to any specific combination of hardware 

The mapping may be stored in and obtained from Configu- circuitry and software. 

ration Data 113. The term "computer-readable medium" as used herein 

In block 424, the authorizations are converted to access is refers to any medium that participates in providing instruc- 

roles that can be used by an access control system such as tions to processor 504 for execution. Such a medium may 

Information Access System 100. When conversion is take many forms, including but not limited to, non- volatile 

complete, one of three paths may be followed. One path is media, volatile media, and transmission media. Non-volatile 

that the process may terminate processing, as indicated by media includes, for example, optical or magnetic disks, such 

the "DONE" block. Another path is that the process may 20 as storage device 510. M)latile media includes dynamic 

persistently store the converted access roles in a registry, for memory, such as main memory 506. Transmission media 

example, using Registry Repository 108, for use later. includes coaxial cables, copper wire and fiber optics, includ- 

Still another path is that the process may carry out ing the wires that comprise bus 502. Transmission media can 

dynamic migration, as indicated by block 428. In dynamic also take the form of acoustic or light waves, such as those 

migration, the access roles are persistently stored in the 25 generated during radio-wave and infira-red data communi- 

access control system in association with user identifying cations, 

information. The remote security server may be decoupled Common forms of computer-readable media include, for 

from the system, as shown by block 432. Thereafter, the example, a floppy disk, a flexible disk, hard disk, magnetic 

access roles are used to authenticate the user. In this way, tape, or any other magnetic medium, a CD-ROM, any other 

authentication information in a legacy remote security server 30 optical medium, punchcards, papertape, any other physical 

isautomatically transferred to the access control system, and medium with patterns of holes, a RAM, a PROM, and 

the legacy remote security server may be retired from EPROM, a FLASH-EPROM, any other memory chip or 

service. cartridge, a carrier wave as described hereinafter, or any 

Hardware Overview other medium from which a computer can read. 

FIG. 5 is a block diagram that illustrates a computer 35 Various forms of computer readable media may be 

system 500 upon which an embodiment of the invention involved in carrying one or more sequences of one or more 

may be implemented. Computer system 500 includes a bus instructions to processor 504 for execution. For example, the 

502 or other communication mechanism for communicating instructions may initially be carried on a magnetic disk of a 

information, and a processor 504 coupled with bus 502 for remote computer. The remote computer can load the instmc- 

processing information. Computer system 500 also includes 40 tions into its dynamic memory and send the instructions over 

a main memory 506, such as a random access memory a telephone line using a modem. A modem local to computer 

(RAM) or other dynamic storage device, coupled to bus 502 system 500 can receive the data on the telephone line and 

for storing information and instructions to be executed by use an infra-red transmitter to convert the data to an infra-red 

processor 504. Main memory 506 also may be used for signal. An infra-red detector can receive the data carried in 

storing temporary variables or other intermediate informa- 4S the in&a-red signal and appropriate circuitry can place the 

tion during execution of instructions to be executed by data on bus 502. Bus 502 carries the data to main memory 

processor 504. Computer system 500 further includes a read 506, from which processor 504 retrieves and executes the 

only memory (ROM) 508 or other static storage device instructions. The instructions received by main memory 506 

coupled to bus 502 for storing static information and instruc- may optionally be stored on storage device 510 either before 

tions for processor 504. A storage device 510, such as a 50 or after execution by processor 504. 

magnetic disk or optical disk, is provided and coupled to bus Computer system 500 also includes a communication 

502 for storing information and instructions. interface 518 coupled to bus 502. Communication interface 

Computer system 500 may be coupled via bus 502 to a 518 provides a two-way data communication coupling to a 

display 512, such as a cathode ray lube (CRT), for displaying network link 520 that is connected to a local network 522. 

information to a computer user. An input device 514, includ- 55 For example, communication interface 518 may be an 

ing alphanumeric and other keys, is coupled to bus 502 for integrated services digital network (ISDN) card or a modem 

communicating information and command selections to to provide a data communication connection to a corre- 

processor 504. Another type of user input device is cursor sponding type of telephone hne. As another example, com- 

conlrol 516, such as a mouse, a trackball, or cursor direction munication interface 518 may be a local area network 

keys for communicating direction information and com- 60 (LAN) card to provide a data communication connection to 

mand selections to processor 504 and for controlling cursor a compatible LAN. Wireless links may also be implemented, 

movement on display 512. This input device typically has In any such implementation, communication interface 518 

two degrees of freedom in two axes, a first axis (e.g., x) and sends and receives electrical, electromagnetic or optical 

a second axis (e.g., y), that allows the device to specify signals that carry digital data streams representing various 

positions in a plane. 65 types of information. 

The invention is related to the use of computer system 500 Network link 520 typically provides data communication 

as an access control system. According to one embodiment through one or more networks to other data devices. For 
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example, network link 520 may provide a connection 
through local network 522 to a host computer 524 or to data 
equipment operated by an Internet Service Provider (ISP) 
526. ISP 526 in turn provides data communication services 
through the world wide packet data commimication network 
now commonly referred to as the "Internet" 528. Local 
network 522 and Internet 528 both use electrical, electro- 
magnetic or optical signals that carry digital data streams. 
The signals through the various networks and the signals on 
network link 520 and through communication internee 518, 
which carry the digital data to and from computer system 
500, are exemplary forms of carrier waves transporting the 
information. 

Computer system 500 can send messages and receive 
data, including program code, through the network(s), net- 
work link 520 and communication interface 518. In the 
Internet example, a server 530 might transmit a requested 
code for an application program through Internet 528, ISP 
526, local network 522 and communication interface 518. In 
accordance with the invention, one such downloaded appli- 
cation provides for an access control system as described 
herein. 

The received code may be executed by processor 504 as 
it is received, and/or stored in storage device 510, or other 
non-volatile storage for later execution. In this manner, 
computer system 500 may obtain application code in the 
form of a carrier wave. 

In the foregoing specification, the invention has been 
described with reference to specific embodiments thereof. It 
will, however, be evident that various modifications and 
changes may be made thereto without departing fi-om the 
broader spirit and scope of the invention. The specification 
and drawings are, accordingly, to be regarded in an illus- 
trative rather than a restrictive sense. 

APPENDIX I 

Methods Used to Access Services Provided by Proxy Secu- 
rity Server 

abstract protected int pam__sm_authenticate(String 
pamh. String args[ ]) 

Any Proxy Security Server Oass should implement this 
method to provide authentication. This is the core of devel- 
oping a Proxy Security Server Classes because authentica- 
tion is the minimum action that a Proxy Security Server 
Classes performs. This method receives the Proxy Security 
Server Class handle (pamh) for the user session and a set of 
arguments. The Proxy Security Server Classes handle is the 
handle that provide extra information about the user, and the 
second parameter is an array of arguments that are passed to 
the authentication method. Currently, the second parameter 
is an empty array. This method should return one of the 
following return codes: 
PAM_SUCCESS— This code is returned when the 

authentication process was successful. 
PAM_j\CCT_EXPlRED— This code is returned when 
the user account is inactive, but the user is authentic. 
PAM_USER_UNKNOWN— This code is returned 
when the user is an unknown user or the userid, 
password combination is not valid. 
PAM_NEW_AUTHTOK_REQD— This code is 
returned when a new password is required, this means 
that the current password has expired or is no longer 
valid for any other reason. 
PAM_CRED_INSUFFiaENT— This code is remraed 
when the credentials are not sufficient to vahdate the 
user. 

PAM_AUTH_ERR— This code is returned when an 
unexpected error occurs. 



PAM_FArA^-This code is returned if there is a fatal 

error in the remote security server, 
abstract protected Thread getNewInstance(String pamh, 
PAMDataShare dataShare) 
5 This method is called to thread out when multiple users 
are using a Proxy Security Server and to perform conver- 
sation back to the user, 
public int getImplementedFunctions( ) 
This method should return the methods implemented by 
the Proxy Security Server Classes. By default, all Proxy 
Security Server Classes implement only authentication. A 
developer does not need to modify overwrite this method if 
the Proxy Security Server Class only performs authentica- 
tion with no other actions. If the Proxy Security Server Qass 
may change authentication profile and authorizations on a 
^5 remote security server, then the Proxy Security Server 
communicates the methods that it can handle. The methods 
that may be handled are specified as return values set to a 
combination of codes shown below. To specify more than 
one code, append the codes together delimited by a '|'. 
20 F__CHAUTHTOK— This code is returned if the Proxy 
Security Server allows passwords to be changed on a 
remote security server. That means that Authentication 
and Authorization Module 114 is free to call pam_ 
chauthtok and this method should already be ovcrwrit- 
25 ten. Please refer to the pam_chauthtok method. 

F_GETPRIVILEGES— This code is returned if the 
Proxy Security Server allows authorization to be 
changed on an remote security server. This means that 
Authentication and Authorization Module 114 is free to 
3Q call pam_^et_privileges and this method should 
already be overwritten. Please refer to the pam__get_ 
privileges method. 
F__GETPRIMARYPRI VILEGES— This code is returned 
if the Proxy Security Server Classes support primary 
35 privileges. What this means is that Information Access 
System 100 identifies primary privileges to be like a 
user type within the Information Access System 100. 
The pam_get_primary_privileges method should be 
implemented because Authentication and Authoriza- 
40 tion Module 114 can call it after authentication. 

F__SETPR0F1LES— This code is returned if the Proxy 
Security Server supports property setting to the external 
system. This means that attributes can be changed in 
the source system and this method is in charge of 
45 setting those attributes. Also, this method is in charge 
of displaying the current values or options to the users 
so that they are aware of the changes, 
public int pam_chauthtok(String pamh) throws PAM- 
HandleException 
50 This method is called by Authentication and Authoriza- 
tion Module 114 when Proxy Security Servers 130 allows 
changing passwords on the system. The pam_chauthtok 
implements, for example, challenging the user and changing 
the user's password in a Remote Security Server 140. 
55 public String[ ]pam_get_43rivileges(String pamh) throws 
PAMHandle Exception 

This method is called by Authentication and Authoriza- 
tion Module 114 when a Proxy Security Server allows 
authorizations to be changed on a Remote Security Server 
60 140. The pam_get_privileges is in charge of retuming a list 
of privileges that the user has in the source system. For 
example, Windows NT users have groups associated with 
them; so, the Proxy Security Server Class can return the list 
of groups associated with the user. These privileges are then 
65 passed to Authentication and Authorization Module 114, 
which is responsible for converting the privileges to access 
roles. 
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public Striag[ ]pam_get_primary_privileges(String 
pamb) throws PAMHandleExoeptioo 

This method is called by Authentication and Authoriza- 
tion Module 114 when remote authorization is enabled. The 
pam_gel jrimary_privileges returns a list of main privi- 
leges that the user has on the Remote Security Server 140. 
For example, under Windows NT Domain Authentication, 
users have a primary group associated with them. The Proxy 
Security Server can return the group associated with the 
user. These primary privileges are then passed to Authenti- 
cation and Authorization Module 114 and Authentication 
and Authorization Module 114 converts the privileges into 
user types. 

public int pam_set_profile (String pamh) throws PAM- 
HandleExceptioD 

This method is called by Authentication and Authoriza- 
tion Module 114 when user profile information may be 
changed on a Remote Security Servers 140. The pam_set_ 
profile changes specific property or attribute information in 
a Remote Security Servers 140 source system. For example, 
a Proxy Security Server allows a user to change their name, 
address, and marital status stored in a user profile on a 
Remote Security Servers 140. This method needs to perform 
the conversation to the user and ask the specific information 
from the user himself. This method should return one of the 
following return codes: 

PAM_SUCCESS-— This code is returned when the 
authentication process was successful. 

PAM_ACCT_EXPIRED— This code is returned when 
the user account is inactive. 

PAM_USER_UNKNOWN— This code is returned 
when the user is a unknown user or the userid, pass- 
word combination is not valid. 

PAM_AUTH_ERR— This code is returned when an 
unexpected error occurs. 

PAM_FArAL — ^This code is returned if there is a fatal 
error in the external system. Either the dynamic library 
did not load correctly or can not communicate with the 
external system with the given configuration. 

public String get__pam ^unique_user(String pamh) 

throws PAMHandleException 

This method is called by Authentication and Authoriza- 
tion Module 114 after authenticating the user. This is the 
unique userid for the user for a specific Proxy Security 
Server Class. The need for this method stems firom the Proxy 
Security Server's ability to handle different users with the 
same userid that reside in different groupings. For example, 
Windows NT Domain Authentication differentiates users 
with the same userid from different domains by pre-pending 
the domain name followed by a back slash "V, The default 
behavior for this method is to return the userid that was 
entered by the user, llierefore, this method does not need to 
be changed if there is no differentiation between users in 
different groupings. 

public void pam_finish_auth(String pamh, String 
gaUserLogin) throws PAMHandleException 

This method allows a Proxy Security Server to perform 
additional tasks after a user a authenticated. For example, 
the Proxy Security Server may save some information in a 
database or flat file. The string gaUserLogin is data identi- 
fying the user in issue. The default behavior is to do nothing. 
This method is only called after user login was successful 
and the user was authenticated. 

public String[ ]get_associated_pam(String pamh, String 
gaUserLogin) throws PAMHandleException 

This method is called after a successful self-registration 
and the Proxy Security Server decides to make the user login 
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to another Proxy Security Server that is not the one that the 
current Proxy Security Server supports. For instance, a 
self-registration for userid/password can request Authenti- 
cation and Authorization Module 114 to associate the user 

5 with LDAP [what is Idap?] because the Proxy Security 
Server might have created the LDAP account. Authentica- 
tion and Authorization Module 114 calls pam_finish_auth 
right after the account is created, but before the association 
of the authentication method. 

10 abstract public String pam_version( ) 

This method needs to be implemented by a Proxy Security 
Server Subclass to return its version. 

abstract public String pam author( ) 

This method needs to be implemented by a Proxy Security 

15 Server Subclass to return the Proxy Security Server Subclass 
author. 

public anyPAAM( ) & public anyPAAM(String name, 
String authSourceName) 

There are two constructors for any Proxy Security Server 
20 Subclass that are used to initialize the base class. These 
constructor can ako initialize private member variables after 
calling the base class. 

public boolean setConfiguration(String array[ ]) 

This method is called by Authentication and Authoriza- 
25 tion Module 114 to set the configuration for a Proxy Security 
Server Class. Extra functionality can be added to this 
method after calling the base class. 

APPENDIX II 

30 Methods Used to Access Services Provided by Authentica- 
tion and Authorization Module 
protected String pam_get_configuration(String key) 
This method is used to get the data about the configuration 
of a Proxy Security Server. You can get any configuration 
35 parameter by just giving the name of the configuration 
parameter. The parameters values are specified by the 
parameter 'config' in Proxy Configuration Data 113. 

protected String pam_getenv(String pamh, String name) 
throws PAMHandleException 
40 This method is used to get any environment variables 
from the Authentication and Authorization Module 114. 
Valid parameter names may be are: 
REMOTE_j\DDR— The IP address firom where the user 
is accessing the information access system. 
^5 SERVER_NAME— The name of the server hosting the 
Web Server communicating with the users browser. 
[Note to inventor: Please explain what this parameter 
is]. 

SERVER_PORT— The port number where the Web 

Server is listening to HTTP requests. 
HTTP_USER_AGENT— The name of the user's 

browser (Netscape, MSIE, etc.). 
HTTP_REFERER— The referrer page. The page that 
55 sent the user to the current script. 

REMOTE_USER— The userid of the user trying being 

authenticated. 

protected Hashtable pam_getenvlist(String pamh) throws 
PAMHandleException 
60 This method is used to get the list of all the environment 
variables that are sent by the Information Access System 
100. This can be used to find out what variables are currently 
be sent by the Information Access System 100. 

public String pam__get_Jtem(String pamh, int itemType) 
65 throws PAMHandleException, PAMSymbolException 

This method is used to get a specific item of information 
related to a session. The possible values for iteml^pe, and 
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the correspondiog information that is returned when the process to perform any action needed by the Proxy Security 

itemlVpe is set, are shown below. Server. The best way to use this method is to store a 

PAMDataShare.PAM_USER— The userid. hashtablc with information and then retrieve them. Asample 

DAK.fn«#„ci,«.o DAx/ Aii^Trw tv.^ usagc is to store information that IS uscd in thc autheutica- 

PAMDataShare.PAM^AUTHTOK--The users pass- ^ Uon method and then retrieve them in the pam_finish„auth 

method. The pam__fimsh_auth is called after a user self 

PAMDataShare.PAM_OLDAUraTOK— The user's old registers. 

password. protected Object get_item_object(String pamh) throws 

PAMDataShare.PAM_^UTH_PURPOSE— The login PAMHandleException 

purpose. This item type is used when the Proxy Secu- This method is used to get an object that set from a 

rity Server Class is configured to perform different previous called method. This method can be used in the 

types authentication. The purposes can be: pam_finish_auth to retrieve the information that was set 

1. AUTH_PURPOSE— Authentication purpose. previously. 

2. SELFREG_PURPOSE— Self-registration purpose. What is claimed is: 

3. OTHERSELFREG_PURPOSE— Adding authenti- 1. A method of selectively authenticating and authorizing 
cation method purpose. a client seeking access to one or more networked computer 

protected Siring pam_get_user(String pamh) throws systems that are protected by an access control system, the 

PAMHandleException method comprising the computer-implemented steps of: 

This method is used to get the userid of the user. This receiving a request of a client to access one of the 

function is exactly the same as calling pam_get_item with computer systems; 

the PAM_USER as the item type. requesting a proxy security server to authenticate the 

protected String[ ]pam_conv(String pamh, int msgType[ client using information identifying the client; 

], String msg[ ]) receiving an authorization of the client from the proxy 

This method is used by a Proxy Security Server to security server based on authentication results received 

communicate back to the user. This is the only way in which ^5 from a remote security server that is coupled to the 

a Proxy Security Server can ask specific questions to the proxy security server; 

user. Hiis method requires the message type and the actual establishing access rights of the client, based on one or 

message. The message types aUowed are: ^^^^ ^^cess information records received from the 

PAM_PROMPT_ECHO_OFF— The message type remote security server through the proxy security 

causes the user input not to be displayed. That means 30 server, for use by the access control system in deter- 

the user will not see what he/she is typing. The text that mining whether to grant the client access to the com- 

is placed as the label will be translated with the p^ter systems. 

message itself. 2. A method as recited in claim 1, wherein requesting a 

PAM_PROMPT_ECHO_ON— The message type is a pnDxy security server to authenticate the client using infor- 

normal input text. The label will be translated with the 35 mation identifying the client comprises requesting a proxy 

message of the same array index. security server, selected from among a plurality of proxy 

PAM_PROMPT_RW — This message type will display a security servers each of which is coupled to and associated 

translated label with a non-translated field that is read with a different remote security server, to authenticate the 

and write. This means that the user will see the current client using information identifying the client, 

value for the label and change it. 40 3. A method as recited in claim 2, wherein receiving an 

PAM_PROMPT_R— This message type will display a authorization of the client comprises receiving an authori- 

translated label with a non-translated field thai is read nation of the cUent from the selected proxy security server 

only. This means that the user will only see the current 0° authentication results received from the remote 

value for the label security server that is coupled to and associated with the 

PAM_ERROR_MSG-Tbis is an error message Ihat « ^l«='f''P'°J^,«'*=""^^^^^^ , , . 

will be displayed in the browser the user is using. The *• ^ "netbod as recited m clami 1. wherein requesting a 

error message is a label that will be translated. P^Y- f '° authenticate the client comprises 

PAM TEXT INFO-This is a textual information that °»<'*°d having an miplementa- 

mT/ 1 J . rJr *"iw*i"»"vu ju*i jjQjj jjj^j specific to the remote secunty server, 

will be displayed to the user. The message is acmally a 5^ ^^^^^^ ^ ^^^^ ^^^^ ^ ^^^^^^ comprising 

label that wui be translated, modifying one or more authorizations that are stored on the 

PAM_NOXLArE_TEXT— This message type is the ^mote security server based on a session identifier associ- 

same as PAM_TEXT_INFO, but the message is not ^^^^j ^j^j^ ^hc client. 

translated. 5 method as recited in claim 1, further comprising 

PAM_CHOICE— The message type is used to generate 55 modifying a user profile that is associated with the client and 

selections that may be selected by the user. Both the stored on the remote security server, 

label and the choices will be translated. The delimiter 7. A method as recited in claim 1, further comprising 

between the label and the choice is a colon (":**). receiving information defining services that the proxy secu- 

PAM_NOXLArE_CHOICE — This message type is the rity server is capable of providing, 

same as PAM_CH01CE with the only difference that 60 8. A method as recited in claim 1, further comprising self 

the choices will not be translated. registering the client in a database of an access control 

protected void set_item_object(String pamh. Object obj) system that controls access to the protected computer sys- 

throws PAMHandleException tems when user identification information received from the 

This method is used to set an object that will be later used client is authenticated by the proxy security server, 

by the Proxy Security Server Classes. This is very useful for 65 9. A method as recited in claim 2, wherein establishing 

storing information when doing self-regisuration because access rights of the client further comprises receiving one or 

some methods are called at the end of the self-registration more authorizations from remote security server through the 
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proxy security server, and converting the authorizations into 
access roles that are associated with the client based on a 
mapping that is stored in within a set of configuration 
information, wherein the configuration information com- 
prises a plurality of blocks of configuration data, wherein 
each block of configuration data is associated with one of the 
proxy security servers. 

10. A method as recited in claim 9, further comprising 
persistently storing the converted access roles in a database 
of an access control system that controls access to the 
protected computer systems. 

11. A method of providing a security mechanism for one 
or more computer systems, the method comprising the steps: 

a first server receiving a message specifying a request to 
register a user that is unregistered on the first server; 

wherein the first server is configured to receive requests to 
authenticate users and supply information that indicates 
access rights of users; 

the first server causing a transmission to a second server 
requesting data that indicates access rights specified by 
the second server for the user; 

wherein the second server is configured to receive 
requests to authenticate users and supply information 
that indicates access rights of users; 

the first server receiving data, transmitted by the second 
server in response to receiving the transmission, that 
indicates access rights specified by the second server 
for the user including at least one authorization; 

storing data that indicates the at least one authorization; 

persistently storing data in one or more access informa- 
tion records that indicates: 
the user is registered on the first server, and 
whether access rights for the user should be obtained 
from the second server; the first server subsequently 
receiving a request to login the user; and 

in response to receiving the request to login the user, 
establishing access rights based on the one or more 
access information records. 

12. The method of claim 11, further including the step of: 
persistently storing data in the one or more access infor- 
mation records that indicates that access rights of the 
user should be obtained from the second server; 

wherein the step of establishing access rights based on the 
one or more access information records includes: 
examining at least a portion of the one or more access 
information records to determine that information 
about access rights of the user should be obtained 
from the second server; and 
in response to determining that information indicating 
that access rights of the user should be obtained from 
the second server, the first server causing the second 
server to supply the at least one authorization. 

13. The method of claim 11, 

wherein the step of storing data that indicates the at least 
one authorization includes persistently storing data in 
the one or more access information records that indi- 
cates the at least one authorization; 

wherein the step establishing access rights based on the 
one or more access information records includes 
generating, from the one or more access information 
records that indicates the at least one authorization, 
data that establishes the authorization as an access 
right. 

14. The method of claim 11, wherein the step of the first 
server causing a transmission includes transmitting to a third 
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server that is dedicated to providing the first server data 
specifying the access rights specified by the second server 
for a set of users. 

15. The method of claim 12, further including the step of 
transmitting a message to one or more other servers that 
specifies a request for access rights specified by each of the 
one or more other servers for a set of users, and 

wherein the third server and the one or more other servers 
communicates with the first server through a API. 

16. A method of providing a security mechanism for one 
or more computer systems, the method comprising the steps: 

a first server receiving a message specifying a request to 
determine access rights of a user registered on the first 
server; 

wherein the first server is configured to receive requests to 
authenticate users and supply information that indicates 
access rights of the users; 

the first server causing a transmission to a second server 
that requests data that indicates the access rights speci- 
fied by the second server for the user; 

wherein the second server is configured to receive 
requests to authenticate users and supply information 
that indicates access rights of users; 

the first server receiving data, transmitted by the second 
server in response to receiving the transmission, that 
indicates a first set of authorizations specified by the 
second server for the user; 

the first server translating data that indicates the first set 
of access rights specified by the second server to one or 
more records that indicates a second set of access rights 
recognized by the first server; and 

establishing a third set of access rights based on the one 
or more records. 

17. The method of claim 16, further including the steps of: 
persistently storing data representing the second set of 

authorizations; 

after persistently storing, the first security server subse- 
quently receiving a request to login the user; and 

in response to receiving the request to login the user, 
establishing access rights that include the second set of 
authorizations based on the persistently stored data. 

18. The method of claim 17, wherein the step of the first 
server translating data includes generating data representing 
access roles that correspond to the first set of authorizations. 

19. A method of providing a security mechanism for one 
or more computer systems, the method comprising the steps: 

causing start up of a plurality of proxy servers that provide 
to a first server data that indicates access rights speci- 
fied for users by a respective server from a second set 
of servers that are each configured to receive requests 
to authenticate users and supply information that indi- 
cates access rights of users; 

the first server transmitting, to each proxy server of the 
pluraUly of proxy servers, a request for data indicating 
the access rights specified by the respective server from 
the second set of servers for a particular user by 
invoking a function of an application programmer 
interface that includes a common set of functions that: 
is associated with the plurality of proxy servers, and 
provides an interface between the first server and the 
second set of servers; and 

in response to each proxy server of the plurality of proxy 
servers receiving the request for data indicating access 
rights of the particular user: 

the each proxy server obtaining information about 
access rights of the particular user from a server of 
the set of servers, and 
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the each proxy server supplying information about 
access rights of the particular user to the first server. 

20. The method of claim 19, wherein the step of the first 
server causing the start up includes instantiating each proxy 
server as an instantiation of a subclass of a parent class that 
defines application program interface. 

21. The method of claim 19, further including the step of 
obtaining user input by performing the steps of: 

a second server firom the set of servers transmitting to a 
first proxy server from the plurality of proxy servers a 
user prompt message that specifies how additional user 
input shoiild be elicited from a user; 
the first server receiving the user prompt message; and 
the first server causing a user interface to obtain user input 
in a manner specified by the user prompt message. 

22. The method of claim 21, wherein the step of obtaining 
user input includes obtaining user input that specifies a user 
profile for the user. 

23. The method of claim 21, wherein the step of obtaining 
user input includes obtaining user input that specifies 
authentication input for the user. 

24. The method of claim 19, further including the steps of: 
the first server receiving data from the first proxy server 

from the plurality of proxy servers that is supplying 
information about access rights of the particular user 
including data indicating that the particular user is 
registered on the respective server from the second set 
of servers; and 
in response to the first server receiving the data fi^om a 
first proxy server, the first server registering the par- 
ticular user. 

25. The method of claim 24, 

wherein the method further includes the steps of present- 
ing a user with a selection of names that each corre- 
spond to a proxy server from the plurality of proxy 
servers; 

selecting a name corresponding to the first proxy server; 
transmitting a request to the proxy server to authenticate 

the particular user; and 
wherein the data from a first proxy server was transmitted 

by the first proxy server in response to the request to 

authenticate. 

26. An access security system, comprising 

a first server configured to receive requests to authenticate 
users and supply information that indicates access 
rights of users; 

a set of one or more servers that are each configured to 
receive requests to authenticate users and supply infor- 
mation that indicates access rights for users; 

a plurality of proxy servers configured to provide to the 
first server data that indicates the access rights specified 
for users by a respective server from the set of one or 
more servers; 

the plurality of proxy servers each configured as instan- 
tiations of a subclass belonging to a base class that 
defines an application program interface through which 
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the plurality of proxy servers and the first server 
interact to provide the first server with information that 
indicates access rights for users; 

a topology mechanism configured to transmit to the first 
server information specifying which proxy server of the 
plurality of proxy servers are running; and 

an access server configured to collect authentication input 
firom a user attempting to log into the access security 
system and to transmit data representing the collected 
authentication input to the first server. 

27. A computer-readable medium carrying one or more 
sequences of instructions which, when executed by one or 
more processors, cause the one or more processors to 
selectively authenticate and authorize a client seeking access 
to one or more protected computer systems over a network, 
by: 

receiving a request of a client to access one of the 

computer systems; 
requesting a proxy security server to authenticate the 

client using information identifying the client; 

receiving an authorization of the client from the proxy 
security server based on authentication results received 
from a remote security server that is coupled to the 
proxy security server; 

establishing access rights of the client based on one or 
more access information records received from the 
remote security server through the proxy security 
server. 

28. An apparatus for selectively authenticating and autho- 
rizing a client seeking access to one or more protected 
computer systems over a network, comprising: 

a processor; and 

a memory having one or more sequences of instructions 
stored therein which, when executed by the processor, 
cause the processor to carry out the computer- 
implemented steps of: 

receiving a request of a client to access one of the 
computer systems; 

requesting a proxy security server to authenticate the 
client using information identifying the client; 

receiving an authorization of the client fi^om the proxy 
security server based on authentication results 
received from a remote security server that is 
coupled to the proxy security server; 

establishing access rights of the client based on one or 
more access information records received from the 
remote security server through the proxy security 
server. 

29. A method as recited in claim 9, further comprising 
persistently storing the converted access roles in a database 
of an access control system that controls access to the 
protected computer systems, whereby authorizations man- 
aged by the remote security server are dynamically migrated 
to the access control system. 
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